[PATCH 0/1][SRU][J] UBUNTU: SAUCE: cifs: fix null pointer dereference in find_ipc_from_server_path

Tue May 5 08:43:00 UTC 2026

From: Ghadi Elie Rahme <ghadi.rahme at canonical.com>

BugLink: https://launchpad.net/bugs/2150730

[Impact]

There is currently a bug in the 5.15 jammy kernel that causes a system crash and has a chance to occur when the connection to a CIFS share drops. The stack trace can be seen below:

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 issue only affects the 5.15 kernel and not latest upstream since it has been indirectly resolved as part of a refactor in commit [6916881f443f cifs: fix refresh of cached referrals].

However backporting this patch to 5.15 is not feasible due to how complicated it is and it also requires extra commits to be backported to apply cleanly. The regression potential is also high.

I have tested two different patches to resolve the issue. One that narrows down the BUG occurrence to a window so small that it becomes extremely hard to hit. And another that completely resolves it using spin_locks. I prefer the first solution since it strikes balance of being good enough with extremely low regression potential. It is also minimizes deviation from upstream.

After sending the original patch to the linux stable mailing list, it was put on hold to wait on a response from the CIFS maintainers: https://lore.kernel.org/stable/20260319144929.455978-1-ghadi.rahme@canonical.com/

However they never answered and I sent another email to CIFS mailing list which also saw no activity: https://lore.kernel.org/linux-cifs/119442fa-7630-482f-ad0a-83c7f61f8786@canonical.com/

This is why I have decided to go with the Ubuntu SAUCE patch to resolve this issue in Ubuntu.

The way the patch works is simple, it will make sure that a tcon is actually still available and being held by the session before accessing it in strcasecmp.

[ Test Plan ]

1. Connect to a CIFS share on jammy using kernel 5.15.

2. Cause network disruption that would make the CIFS share connect and disconnect often

3. With the current kernel the machine will eventually crash, however if the patch fixes the problem the machine should remain up and running.

[ Where problems could occur ]

The regression potential is low since the code path would crash in a scenario where the tcon is null. The function does handle the error scenario where no entry is found correctly. This means that there is a chance of another bug or crash being hit in the calling function if it does not handle this error code appropriately.

Ghadi Elie Rahme (1):
  cifs: fix null pointer dereference in find_ipc_from_server_path

 fs/cifs/dfs_cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.53.0