CVE-2024-56631

What it actually does

Use-after-free in sg_release() where kref_put may trigger sg_remove_sfp cleanup and free sfp while the open_rel_lock mutex is still held, allowing subsequent unlock and reference operations on the freed object.

Why it matters to the business

Local attackers on affected Linux systems can crash the kernel or potentially escalate privileges, leading to denial of service, data exposure, or full system compromise on servers and endpoints running vulnerable kernels.

How an attack unfolds

An attacker with local access opens an sg device, triggers the release path under contention so that kref_put frees the sfp structure via deferred work, then the continuing unlock and references in sg_release dereference the now-freed slab object, enabling memory corruption or information disclosure.

How to fix it

Upgrade the Linux kernel to commit e19acb1926c4a1f30ee1ec84d8afba2d975bd534 or later; apply the stable backports that reorder kref_put after mutex_unlock in sg_release(). Reboot systems after kernel update.

How to confirm the fix worked

Verify the running kernel contains the fix commit, confirm sg.c no longer calls kref_put before mutex_unlock in sg_release(), and re-run syzbot-style KASAN tests or equivalent dynamic analysis on the sg driver.

Typical attack path

1. Obtain local user access on a vulnerable Linux system
2. Open /dev/sg* or equivalent SCSI generic device
3. Trigger concurrent release operations that race on open_rel_lock and kref_put
4. Cause sg_remove_sfp to free sfp while sg_release continues to access it
5. Leverage the resulting use-after-free for memory corruption or info leak

How to detect it

Search kernel logs and audit trails for KASAN slab-use-after-free reports involving sg_release, lock_release, or __mutex_unlock_slowpath; inspect crash dumps for references to sfp or sdp structures after kref_put.

What your security team should do

• Prioritize kernel updates on all internet-facing and multi-user Linux systems within the next patching cycle
• Restrict unprivileged access to /dev/sg* devices via udev or group permissions until patched
• Monitor kernel logs for KASAN reports mentioning sg_release or lockdep in mutex paths
• Test the updated kernel in staging environments before broad deployment