CVE-2025-37952

What it actually does

Use-after-free in ksmbd due to insufficient refcount protection on fp objects in __close_file_table_ids, allowing one thread to free a file descriptor while another concurrently retrieves it via the IDR without holding ft->lock.

Why it matters to the business

Kernel memory corruption on Linux systems hosting SMB shares can cause crashes, denial of service, or local privilege escalation, disrupting file services and exposing the host to further compromise.

How an attack unfolds

An attacker with network access to ksmbd or local code execution triggers a race between __ksmbd_close_fd and functions that fetch file pointers from the IDR; concurrent threads acquire the same dangling pointer after one frees it, leading to memory corruption. Similar kernel privilege-escalation patterns seen in related CVEs demonstrate how this can be chained for root access.

How to fix it

Apply the upstream fix in commit fec1f9e9a650e8e7011330a085c77e7bf2a08ea9 or later stable kernels; rebuild and reboot with the patched kernel. Disable ksmbd if SMB services are not required.

How to confirm the fix worked

Confirm the running kernel contains commit fec1f9e9a650e8e7011330a085c77e7bf2a08ea9 via git log or uname -r against a known fixed distribution build; attempt to reproduce the race under load to verify absence of UAF.

Typical attack path

1. Establish SMB session to ksmbd
2. Trigger concurrent file open/close operations from multiple threads or connections
3. Race __close_file_table_ids removal against IDR lookup paths
4. Reuse freed file pointer to corrupt kernel memory structures
5. Escalate privileges or crash the kernel

How to detect it

Review kernel logs for oops/panic messages referencing ksmbd, __close_file_table_ids, or IDR file table operations; correlate with SMB connection spikes and audit user-space processes performing rapid file operations on SMB shares.

• ksmbd: __close_file_table_ids
• UAF in ksmbd file table
• ft->lock ksmbd
• kernel BUG at fs/smb/server/vfs.c

What your security team should do

• Immediately upgrade affected kernels to a version containing fec1f9e9a650e8e7011330a085c77e7bf2a08ea9
• Restrict ksmbd exposure to trusted networks only
• Monitor for related kernel memory corruption reports in ksmbd
• Plan kernel updates within the next maintenance window given the 500+ days since disclosure