CVE-2025-38244

In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix potential deadlock when reconnecting channels

Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order

and prevent the following deadlock from happening

======================================================

WARNING: possible circular locking dependency detected

6.16.0-rc3-build2+ #1301 Tainted: G S W

------------------------------------------------------

cifsd/6055 is trying to acquire lock:

ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200

but task is already holding lock:

ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}:

validate_chain+0x1cf/0x270

__lock_acquire+0x60e/0x780

lock_acquire.part.0+0xb4/0x1f0

_raw_spin_lock+0x2f/0x40

cifs_setup_session+0x81/0x4b0

cifs_get_smb_ses+0x771/0x900

cifs_mount_get_session+0x7e/0x170

cifs_mount+0x92/0x2d0

cifs_smb3_do_mount+0x161/0x460

smb3_get_tree+0x55/0x90

vfs_get_tree+0x46/0x180

do_new_mount+0x1b0/0x2e0

path_mount+0x6ee/0x740

do_mount+0x98/0xe0

__do_sys_mount+0x148/0x180

do_syscall_64+0xa4/0x260

entry_SYSCALL_64_after_hwframe+0x76/0x7e

-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}:

validate_chain+0x1cf/0x270

__lock_acquire+0x60e/0x780

lock_acquire.part.0+0xb4/0x1f0

_raw_spin_lock+0x2f/0x40

cifs_match_super+0x101/0x320

sget+0xab/0x270

cifs_smb3_do_mount+0x1e0/0x460

smb3_get_tree+0x55/0x90

vfs_get_tree+0x46/0x180

do_new_mount+0x1b0/0x2e0

path_mount+0x6ee/0x740

do_mount+0x98/0xe0

__do_sys_mount+0x148/0x180

do_syscall_64+0xa4/0x260

entry_SYSCALL_64_after_hwframe+0x76/0x7e

-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}:

check_noncircular+0x95/0xc0

check_prev_add+0x115/0x2f0

validate_chain+0x1cf/0x270

__lock_acquire+0x60e/0x780

lock_acquire.part.0+0xb4/0x1f0

_raw_spin_lock+0x2f/0x40

cifs_signal_cifsd_for_reconnect+0x134/0x200

__cifs_reconnect+0x8f/0x500

cifs_handle_standard+0x112/0x280

cifs_demultiplex_thread+0x64d/0xbc0

kthread+0x2f7/0x310

ret_from_fork+0x2a/0x230

ret_from_fork_asm+0x1a/0x30

other info that might help us debug this:

Chain exists of:

&tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock

Possible unsafe locking scenario:

CPU0 CPU1

---- ----

lock(&ret_buf->chan_lock);

lock(&ret_buf->ses_lock);

lock(&ret_buf->chan_lock);

lock(&tcp_ses->srv_lock);

*** DEADLOCK ***

3 locks held by cifsd/6055:

#0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200

#1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200

#2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200