CVE-2025-21673

What it actually does

Double free of the hostname field in TCP_Server_Info during CIFS session shutdown when the cifsd thread is still processing DFS reconnections, leading to use-after-free and slab corruption in the kernel.

Why it matters to the business

Kernel crashes or system instability on Linux hosts using SMB/CIFS file shares with DFS, potentially causing unplanned downtime and requiring reboots in environments with heavy network filesystem usage.

How an attack unfolds

An attacker or local process triggers CIFS session termination conditions while the cifsd demultiplex thread is inside the reconnection loop for multiple DFS targets; the hostname pointer is freed once during shutdown and again when extract_hostname runs, resulting in slab double-free and kernel panic.

How to fix it

Upgrade the Linux kernel to a version containing commit 1ea68070338518a1d31ce71e6abfe1b30001b27a or later stable releases that include the fix for double-free of TCP_Server_Info::hostname in the CIFS client.

How to confirm the fix worked

Verify the running kernel git commit or version contains 1ea68070338518a1d31ce71e6abfe1b30001b27a; reproduce DFS reconnection scenarios and confirm absence of slab double-free oops in dmesg during cifs_put_tcp_session shutdown.

Typical attack path

1. Mount or access an SMB share configured with DFS namespaces
2. Trigger conditions that cause cifs_put_tcp_session to run while reconnections are active
3. Force the cifsd thread to execute __reconnect_target_unlocked and extract_hostname after the first free
4. Trigger the second free leading to __slab_free invalid operation and kernel oops

How to detect it

Search kernel logs and dmesg for oops traces containing __slab_free combined with cifs functions such as extract_hostname, __reconnect_target_unlocked, reconnect_dfs_server, or cifs_demultiplex_thread; look for RIP patterns matching slab free invalid operations during session shutdown.

• __reconnect_target_unlocked+0x3e/0x160 [cifs]
• extract_hostname+0x5c/0xa0 [cifs]
• reconnect_dfs_server+0x145/0x430 [cifs]
• cifs_handle_standard+0x1ad/0x1d0 [cifs]
• __slab_free+0x223/0x3c0

What your security team should do

• Apply the referenced kernel commit or newer stable branch immediately on all systems using the CIFS client
• Monitor for kernel oops involving cifs and __slab_free in production logs
• Limit use of DFS namespaces over CIFS until patches are deployed if possible