CVE-2025-38717

What it actually does

Race condition in kcm_unattach() missing kcm->tx_stopped check before queue_work(), allowing tx_work requeue between cancel_work_sync() and unreserve_psock() in kcm_release(), resulting in use-after-free when kcm is freed in kcm_done().

Why it matters to the business

Kernel instability, crashes, or potential privilege escalation on Linux systems using KCM sockets, increasing risk of service disruption or compromise until patched.

How an attack unfolds

An attacker concurrently invokes kcm_unattach(psock) and kcm_release(kcm) via crafted socket operations to trigger the race, requeuing tx_work after the kcm object is freed and enabling use-after-free exploitation.

How to fix it

Update the Linux kernel to a version containing commit c0bffbc92a1ca3960fb9cdb8e9f75a68468eb308 or later equivalent fix; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the running kernel includes the referenced commit via git log or version string checks; attempt to reproduce the original syzbot race scenario post-update to verify absence.

Typical attack path

1. Open and configure KCM sockets to establish a reserved psock
2. Trigger concurrent kcm_unattach and kcm_release calls through multithreaded or asynchronous socket operations
3. Exploit resulting use-after-free for denial of service or code execution

How to detect it

Inspect kernel logs and dmesg for oops, warnings, or crashes referencing kcm, tx_work, or kcm_release around the time of suspected activity.

What your security team should do

• Prioritize kernel updates across all affected Linux deployments
• Review and restrict use of KCM sockets where possible until patched
• Monitor kernel logs for related oops or crashes during rollout