CVE-2024-53186

What it actually does

Race condition in ksmbd allows use-after-free of ksmbd_conn structure during concurrent SMB request handling and workqueue processing, enabling access to freed memory via waitqueue operations.

Why it matters to the business

Systems exposing SMB shares via the Linux kernel ksmbd module risk kernel crashes, denial of service, or potential elevation of privileges from local or network attackers until patched.

How an attack unfolds

An attacker establishes an SMB connection and issues requests that keep the connection handler waiting on reference count while the workqueue handler decrements it to zero and frees the structure, then triggers further accesses to the freed waitqueue leading to UAF.

How to fix it

Update the Linux kernel to a version containing commit 98f7e32f20d28ec452afb208f9cffc08448a2652 or later; disable ksmbd if SMB server functionality is not required.

How to confirm the fix worked

Verify kernel source contains the referenced commit, rebuild and boot the fixed kernel, then confirm absence of KASAN reports for slab-use-after-free in handle_ksmbd_work and ksmbd_conn_handler_loop under load.

Typical attack path

1. Establish SMB session to trigger ksmbd_conn allocation
2. Send crafted or timed SMB requests to hold reference count
3. Force workqueue path that decrements count to zero and frees conn
4. Access freed conn via wait_event or wake_up on r_count_q
5. Leverage resulting slab UAF for memory corruption or info leak

How to detect it

Search kernel logs and KASAN output for slab-use-after-free messages referencing handle_ksmbd_work, ksmbd_conn_handler_loop, rtlock_slowlock_locked, or ksmbd_conn_free; inspect crash dumps for references to conn->r_count_q after free.

• slab-use-after-free Read in handle_ksmbd_work
• KASAN: slab-use-after-free in rtlock_slowlock_locked
• wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0)
• atomic_dec_return(&conn->r_count)
• waitqueue_active(&conn->r_count_q)
• ksmbd_conn_free

What your security team should do

• Apply the kernel fix containing commit 98f7e32f20d28ec452afb208f9cffc08448a2652 immediately on all systems running ksmbd
• Audit configurations for unnecessary ksmbd exposure and disable the module where possible
• Monitor for kernel oops or KASAN warnings involving ksmbd_conn structures
• Test patched kernels in staging before production rollout