Look up another CVE · open CVE-2025-38244 in the interactive tracker

CVE-2025-38244

smb: client: fix potential deadlock when reconnecting channels

7.5 EPSS 0.3% AV:N

Published 2025-07-09 (15 months ago) by the Linux kernel CNA. Subsystem fs/smb. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2025-38244 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	vulnerable	6.1.190-1	No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication.
Debian 13trixie	fixed	6.12.37-1	Update the kernel and reboot. Fixed in 6.12.37-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	6.12.37-1	Update the kernel and reboot. Fixed in 6.12.37-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	6.12.37-1	Update the kernel and reboot. Fixed in 6.12.37-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

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

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

fs/smb/client/cifsglob.h
fs/smb/client/connect.c

What this is: COMMON INTERNET FILE SYSTEM CLIENT (CIFS and SMB3)MAINTAINERS section matched on fs/smb/client/ · linux-cifs@vger.kernel.org · Supported
Kernel module: cifs

Check it on the machine

grep -wE 'CONFIG_CIFS|CONFIG_SMBFS' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w cifs

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

bookworm, trixie, forky, sidm

m: a loadable module on every flavour - check lsmod, can be blacklisted

Build switches: CONFIG_CIFS, CONFIG_SMBFS
Reads as: all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2025-07-09 (15 months ago)source
CVSS: 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.25%, higher than 15.6% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: fs/smb

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
6.0	6.6.96	c82c7041258d
6.0	6.12.36	7f3ead8ebc0e
6.0	6.15.5	fe035dc78aa6
6.0	6.16	711741f94ac3

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network: The vulnerable function is reached from `cifs_demultiplex_thread` while parsing data received from a remote SMB server (short/oversized RFC1002 PDUs, malformed compound `next_header`, `STATUS_NETWORK_SESSION_EXPIRED`), so a malicious/compromised SMB server or an attacker injecting into an unsigned SMB connection triggers it over the network. The DFS-referral and SMB-witness callers are likewise driven by remote server responses.
AC:LAttack complexity, low: The attacker can force `cifs_reconnect(server, true)` into the inverted `chan_lock → srv_lock` sequence deterministically and at unbounded rate with a single malformed response, and the reconnect storms he causes themselves drive the opposing `ses_lock → chan_lock` session-setup path on other channel threads. No rare kernel config is needed — the loop starts at index 0, so even a single-channel mount takes the inverted order.
PR:NPrivileges required, none: The attacker needs no account or privilege on the victim client; the reconnect triggers are evaluated on the received header before signature verification in `handle_mid()`, and the demux thread runs from `cifs_get_tcp_session()` onward, making the path reachable pre-authentication.
UI:NUser interaction, none: On an already-mounted share — the normal enterprise/cloud case — a compromised server or on-path attacker triggers the path with no victim action at all; no new mount, file open, or any other local operation is required.
S:UScope, unchanged: The deadlock is confined to the kernel's own locking of the CIFS client and does not cross into another security authority such as a hypervisor or IOMMU boundary.
C:NConfidentiality impact, none: This is purely a lock-acquisition-order defect; no memory is read out of bounds, no freed object is dereferenced, and no kernel data is exposed to the attacker.
I:NIntegrity impact, none: No memory is written out of bounds or after free and no control-flow structure is corrupted, so the bug yields no data-modification or write primitive.
A:HAvailability impact, high: The circular dependency is between raw `spin_lock()`s, so closing the cycle spins CPUs with preemption disabled into an unrecoverable hard lockup that hangs the cifsd thread, the mount path, and the whole system; on `panic_on_warn` kernels the lockdep WARNING alone is an immediate panic.