From: Ghadi Rahme <ghadi.rahme@canonical.com>
To: linux-cifs@vger.kernel.org
Cc: Steve French <sfrench@samba.org>
Subject: RFC: kernel NULL pointer dereference affecting stable
Date: Fri, 17 Apr 2026 20:24:37 +0300 [thread overview]
Message-ID: <119442fa-7630-482f-ad0a-83c7f61f8786@canonical.com> (raw)
There is a kernel NULL pointer dereference affecting kernel 6.1 lts and
5.15 lts. The bug happens in `find_ipc_from_server_path` when strcmp is
called with `(*ses)->tcon_ipc` equal to NULL. This state can happen and
has been observed to happen when the client disconnects from the server
at the right time. Below is the stack trace:
BUG: kernel NULL pointer dereference, address: 0000000000000050
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 1013dc64067 P4D 10125f65067 PUD 10125f64067 PMD 0
Oops: 0000 [#1] SMP NOPTI
CPU: 80 PID: 3913754 Comm: kworker/u256:1 Kdump: loaded Not tainted
5.15.0-143-generic #153-Ubuntu
Hardware name: Dell Inc. PowerEdge R760/09XV41, BIOS 2.3.5 09/10/2024
Workqueue: cifs-dfscache refresh_cache_worker [cifs]
RIP: 0010:strcasecmp+0x19/0x50
Code: 01 84 c9 75 f1 c3 cc cc cc cc 0f 1f 80 00 00 00 00 49 89 f9 31
ff 41 0f b6 04 39 0f b6 c8 89 c2 83 c2 20 f6 81 e0 39 89 85 01 <0f> b6
0c 3e 0f b6 d2 0f 45 c2 89 ca 44 0f b6 c1 83 c2 20 41 f6 80
RSP: 0018:ff4043e68aadb900 EFLAGS: 00010246
RAX: 000000000000005c RBX: ff4043e68aadbc68 RCX: 000000000000005c
RDX: 000000000000007c RSI: 0000000000000050 RDI: 0000000000000000
RBP: ff4043e68aadb990 R08: 0000000000000064 R09: ff4043e68aadb91f
R10: 0000000000000012 R11: 0000000000000000 R12: ff210c171f193c00
R13: 0000000000000009 R14: 0000000000000008 R15: ff210d1d3f19a7c0
FS: 0000000000000000(0000) GS:ff210d127fc00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000050 CR3: 0000011f2cc38005 CR4: 0000000000771ee0
PKRU: 55555554
Call Trace:
<TASK>
? find_ipc_from_server_path+0xd9/0x110 [cifs]
refresh_cache+0xf1/0x470 [cifs]
? in4_pton+0x7a/0x160
? kfree+0x1f7/0x250
? target_share_equal+0x198/0x210 [cifs]
? __refresh_tcon.isra.0+0x242/0x670 [cifs]
? kfree+0x1f7/0x250
? __refresh_tcon.isra.0+0x242/0x670 [cifs]
? cifs_put_tcon.part.0+0x39/0x220 [cifs]
? cifs_put_tcon+0x1c/0x30 [cifs]
? refresh_mounts+0x147/0x210 [cifs]
refresh_cache_worker+0x1ac/0x300 [cifs]
? lock_timer_base+0x3b/0xd0
process_one_work+0x228/0x3d0
worker_thread+0x53/0x420
? process_one_work+0x3d0/0x3d0
kthread+0x127/0x150
? set_kthread_struct+0x50/0x50
ret_from_fork+0x1f/0x30
</TASK>
The bug has been indirectly fixed upstream in commit
6916881f443f67f6893b504fa2171468c8aed915 which remove
`find_ipc_from_server_path`.
Backporting the upstream commit to 6.1 and 5.15 stable seems risky since
it does not cleanly apply and requires extra commits to apply correctly.
Do the maintainers believe that going though and backporting this commit
with any extra needed commits to 5.15 and 6.1 LTS is the correct way
forward here?
I have already tested two solutions. The first one doesn't fully resolve
the issue however it is simple, safe and massively narrow down the
probability of the BUG occurring. The second is a bit more risky but
fully resolves the issue and I achieved it by adding a few spinlocks.
I am not a fan of option 2 since I found a commit that directly dealt
with a lock contention bug in CIFS by splitting one spin lock into many,
and I would like not to add extra pressure on the spinlock in 5.15.
It was tested for days with no issues, however there is always a chance
that it might introduce deadlocks. The deviation from upstream would
also be greater with such a patch.
For Option 1 I had send a patch to stable 6.1 [1] and 5.15 [2], which
was rejected due to deviating from upstream (See email thread of [2]).
So I guess my question for the maintainers is, is it worth the risk to
backport commit 6916881f443f67f6893b504fa2171468c8aed915 to 6.1 and 5.15
LTS with any needed extra commits with it, try again with option 1, or
is the regression potential not worth fixing it in the LTS kernels?
I was asked in [3] to coordinate this with CIFS maintainers.
Thank you in advance.
[1]
https://lore.kernel.org/stable/20260319144929.455978-1-ghadi.rahme@canonical.com/
[2]
https://lore.kernel.org/stable/20260319144325.438788-1-ghadi.rahme@canonical.com/
[3] https://lore.kernel.org/stable/2026033136-refining-ladybug-08b0@gregkh/
reply other threads:[~2026-04-17 17:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=119442fa-7630-482f-ad0a-83c7f61f8786@canonical.com \
--to=ghadi.rahme@canonical.com \
--cc=linux-cifs@vger.kernel.org \
--cc=sfrench@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).