CVE-2024-35954

What it actually does

Race condition in sg_remove_sfp_usercontext allows sg_device_destroy to dereference a NULL request_queue after scsi_device_put removes the last reference to the parent scsi_device, resulting in a kernel NULL pointer exception and crash.

Why it matters to the business

Unpatched Linux systems using the SCSI generic driver can experience sudden kernel panics that halt services, cause data loss, and require reboots, increasing downtime and operational risk especially on storage or server workloads.

How an attack unfolds

An attacker with local access triggers concurrent sg device removal and reference-counting operations; the flawed ordering lets sg_device_destroy access a freed or NULL queue pointer, crashing the kernel. No remote or unauthenticated path is described.

How to fix it

Upgrade the Linux kernel to a version containing commit 46af9047523e2517712ae8e71d984286c626e022 or later; rebuild and reboot affected systems. Where immediate patching is impossible, restrict untrusted local access to sg devices via device permissions or SELinux/AppArmor policies.

How to confirm the fix worked

Verify the running kernel contains commit 46af9047523e2517712ae8e71d984286c626e022 or a back-port; reproduce the race under stress testing and confirm absence of NULL dereference oops; monitor kernel logs for sg/scsi_device related panics post-upgrade.

Typical attack path

1. Obtain local execution on a Linux host exposing /dev/sg* devices
2. Issue concurrent sg ioctl or open/close operations that race device teardown
3. Force scsi_device_put to drop the final reference while sg_remove_sfp_usercontext still runs
4. Trigger NULL dereference inside sg_device_destroy on the now-NULL request_queue
5. Kernel oops/panic completes the denial-of-service

How to detect it

Search kernel logs and crash dumps for oops/panic traces containing sg_remove_sfp_usercontext, sg_device_destroy, or scsi_device_put; correlate with sg device open/close activity around the timestamp of the crash.

• sg_remove_sfp_usercontext
• sg_device_destroy
• scsi_device_put
• NULL pointer dereference in sg
• request_queue.*NULL

What your security team should do

• Apply the referenced kernel commit within the next maintenance window
• Audit systems for use of the sg driver and prioritize high-value servers
• Enable kernel panic logging and watchdog timers to accelerate recovery
• Restrict local user access to /dev/sg* until patches are deployed
• Track EPSS and KEV status for any future changes in exploit availability