Summary:
A regression bug in the Linux kernel SCSI core could cause kernel warnings and potential resource leaks when a SCSI host is allocated but never fully added due to early errors, especially visible in certain error-handling paths (notably with the usb-storage driver). This post explains what happened, why it mattered, and how it was fixed, with code examples and real-world impact.

What is CVE-2024-26935?

CVE-2024-26935 is a vulnerability discovered and fixed in the Linux kernel affecting SCSI (Small Computer System Interface) subsystems. The bug specifically involves the handling of procfs directories created for each SCSI host. If a SCSI host is allocated but never *added* (due to an error), the proc directory for that host may not be removed, leading to "already registered" warnings and potential kernel resource leaks.

The bug was triggered by regression after a previous fix was introduced to solve module loading/unloading issues, which in turn created the new problem in rare error paths.

Original Cleanup Attempt

- Earlier, /proc/scsi/$DRIVER directories were not being removed on time, which was fixed by making sure scsi_proc_hostdir_rm() is called early.
- Commit: fc663711b944

Regression Introduced

- The fix made it possible for scsi_proc_hostdir_rm() to be called twice (from scsi_remove_host() and scsi_host_dev_release()), causing new warnings.

Call to scsi_proc_hostdir_rm() was removed from scsi_host_dev_release().

- Replacement fix: be03df3d4bfe

Who Can Trigger It? Example: usb-storage Driver Error Path

When loading a USB storage device, the usb-storage driver allocates a SCSI host. If the process fails before the host is fully added (like on the "BadDevice" branch), the proc entry is left dangling.

dmesg shows

usb-storage 4-1:87.51: USB Mass Storage device detected
proc_dir_entry 'scsi/usb-storage' already registered
WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+x347/x4e fs/proc/generic.c:376

Key Functions

- scsi_host_alloc(): Allocates a SCSI host and also creates a /proc/scsi/ directory for it.

The Problem

In cases where allocation occurs, but addition never happens, the cleanup needed to remove the procfs directory doesn't run, causing problems if the driver/module gets reloaded.

The Patch: Smart Cleanup with a State Check!

Linux maintainers realized that you cannot just "remove the cleanup" from scsi_host_dev_release()—that cleanup is still required in the error path. The fix: only call the removal helper if the host actually made it to the "created" state.

Code Snippet (final fix)

// Only run removal if host was actually created!
if (test_bit(SHOST_CREATED, &shost->shost_state))
    scsi_proc_hostdir_rm(shost);

- This check happens in scsi_host_dev_release(), so hosts that made it past scsi_add_host() get their cleanup from scsi_remove_host(), and error-path hosts are cleaned up here without causing double free warnings.

Patch Reference:
- Linux kernel commit 61040c99bdc
- Linux SCSI mailing list report: LKML thread

Impact and Exploitation

- Local attackers could use rapid module load/unload cycles, or Syzkaller-like fuzzing to trigger warning messages and resource leaks, possibly leading to a denial of service over time (if host structures are leaked).

No direct privilege escalation is known, but repeated resource leaks can destabilize a system.

- Syzkaller, a kernel fuzzing tool, triggered this bug while testing the usb-storage interface in an automated way.

An attacker could repeatedly force the driver to error during probing

modprobe usb-storage
# Unplug device mid-probe, or use a faulty/bad USB drive with rapid plug/unplug cycles.
rmmod usb-storage

This pattern can cause the error code path to be hit multiple times, causing the /proc/scsi/usb-storage leftover and eventual kernel warnings.

How to Patch

- Upgrade to a kernel with the patched commit: Make sure your kernel includes the fix described above. Most major distros will backport this to upcoming stable releases.

To check if you're vulnerable:
If you notice the "proc_dir_entry ... already registered" messages in dmesg after USB storage errors or load/unload cycles, you still have the bug.

References

- Commit introducing the regression: fc663711b944
- Original regression fix: be03df3d4bfe
- Final fix: 61040c99bdc
- Kernel mailing list thread
- CVE-2024-26935 at cve.mitre.org

Conclusion

CVE-2024-26935 is a clear example of how error paths and resource cleanup matter deeply in kernel programming. Double-checking for cleanup in all paths, especially for procfs entries (which interact with the whole OS), is critical to prevent resource leaks and kernel warnings—even if the impact isn't immediately exploitable. This fix is now in mainline and should land in all supported Linux distributions soon.

> Stay updated and always check your kernel logs after odd hardware failures or debugging—sometimes the smallest warnings reveal the most interesting bugs!

Timeline

Published on: 05/01/2024 06:15:08 UTC
Last modified on: 05/04/2025 12:55:14 UTC