kernel panic using CIFS share in smb2_push_mandatory_locks()
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
High
|
Guilherme G. Piccoli | ||
Xenial |
Invalid
|
Undecided
|
Guilherme G. Piccoli | ||
Bionic |
Fix Released
|
High
|
Guilherme G. Piccoli | ||
Cosmic |
Won't Fix
|
High
|
Guilherme G. Piccoli | ||
Disco |
Fix Released
|
High
|
Guilherme G. Piccoli | ||
linux-azure (Ubuntu) |
Fix Released
|
Critical
|
Unassigned | ||
Xenial |
Fix Released
|
Critical
|
Unassigned | ||
Bionic |
Invalid
|
Undecided
|
Unassigned | ||
Cosmic |
Invalid
|
Undecided
|
Unassigned | ||
Disco |
Invalid
|
Undecided
|
Unassigned |
Bug Description
NOTICE: The new patch merge is being worked on https:/
[Impact]
* We got reports of a kernel crash in cifs module with the following signature:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
IP: smb2_push_
PGD 0 P4D 0
RIP: 0010:smb2_
Call Trace:
cifs_oplock_
process_
worker_
kthread+
[...]
* Low-level analysis (decodecode script output and the objdump of the function) revealed that we are crashing in a NULL ptr dereference when trying to access "cfile->tlink"; below, a snippet of the objdump at function smb2_push_
[...]
mov 0x10(%r14),%r15 # %r15 = cifsFileInfo *cfile
mov 0x18(%r14),%rbx # %rbx = cifsLockInfo *li = (fdlocks->locks)
lea 0x18(%r14),%r12
mov 0x90(%r15),%rax # %rax = struct tcon_link *tlink (cfile->tlink)
cmp %r12,%rbx
mov 0x38(%rax),%rax # <--- TRAP [trying to get cifs_tcon *tl_tcon]
[...]
* After discussing the issue with CIFS maintainers (Steve French and Pavel Shilovsky) they suggested commit b98749cac4a6 ("CIFS: keep FileInfo handle live during oplock break") [http://
* The fix was sent to stable kernels and is present in Ubuntu kernels 5.0 and newer. We are requesting the SRU for this patch here in order to fix the crashes, after reports of successful testing with the patch (see below section) and since the patch is restricted to the cifs module scope and accepted on linux stable.
* Alternatively the issue is known to be avoided when oplocks are disabled using "cifs.enable_
[Test case]
* Unfortunately we cannot reproduce the issue. The patch proposed here was
validated by us with xfstests (instructions followed from
https:/
have a user report of test validation using LISA (https:/
* Using xfstest with the exclusions proposed in the link above we managed to get the same results as a non-patched kernel, i.e., the same tests failed in both kernels, we didn't get worse results with the patch. Fio also didn't show noticeable performance regression with the patch.
[Regression potential]
* The patch was validated by the cifs filesystem maintainers (in fact they suggested its inclusion in Ubuntu) and by the aforementioned tests; also, the scope is restricted to cifs only so the likelihood of regressions is considered low.
* Due to the nature of the code modification (add a new reference of a file handler and manipulate it in different places), I consider that if we have a regression it'll manifest as deadlock/blocked tasks, not something more serious like crashes or data corruption.
tags: | added: sts |
Changed in linux (Ubuntu Cosmic): | |
status: | New → Confirmed |
Changed in linux (Ubuntu Disco): | |
status: | New → Confirmed |
Changed in linux (Ubuntu Cosmic): | |
importance: | Undecided → High |
Changed in linux (Ubuntu Disco): | |
importance: | Undecided → High |
Changed in linux (Ubuntu Cosmic): | |
assignee: | nobody → Guilherme G. Piccoli (gpiccoli) |
Changed in linux (Ubuntu Disco): | |
assignee: | nobody → Guilherme G. Piccoli (gpiccoli) |
Changed in linux (Ubuntu Disco): | |
status: | Confirmed → Fix Released |
Changed in linux (Ubuntu Cosmic): | |
status: | Confirmed → Won't Fix |
Changed in linux (Ubuntu Bionic): | |
status: | Confirmed → In Progress |
summary: |
- kernel panic using CIFS share smb2_push_mandatory_locks + kernel panic using CIFS share in smb2_push_mandatory_locks() |
description: | updated |
description: | updated |
Changed in linux (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Xenial): | |
status: | New → Invalid |
Changed in linux-azure (Ubuntu Bionic): | |
status: | New → Invalid |
Changed in linux-azure (Ubuntu Cosmic): | |
status: | New → Invalid |
Changed in linux-azure (Ubuntu Disco): | |
status: | New → Invalid |
Changed in linux-azure (Ubuntu): | |
importance: | Undecided → Critical |
status: | New → Confirmed |
Changed in linux-azure (Ubuntu Xenial): | |
importance: | Undecided → Critical |
Changed in linux-azure (Ubuntu Xenial): | |
status: | New → Fix Committed |
tags: | added: cscc |
Changed in linux-azure (Ubuntu): | |
status: | Confirmed → Fix Released |
Changed in linux (Ubuntu Xenial): | |
assignee: | nobody → Guilherme G. Piccoli (gpiccoli) |
Changed in linux (Ubuntu): | |
status: | Confirmed → Fix Released |
Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?
Would it be possible for you to test the latest upstream kernel? Refer to https:/ /wiki.ubuntu. com/KernelMainl ineBuilds . Please test the latest v4.19 kernel[0].
If this bug is fixed in the mainline kernel, please add the following tag 'kernel- fixed-upstream' .
If the mainline kernel does not fix this bug, please add the tag: 'kernel- bug-exists- upstream' .
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".
Thanks in advance.
[0] http:// kernel. ubuntu. com/~kernel- ppa/mainline/ v4.19-rc6