Vulnerability CVE-2024-26935
Published: 2024-05-01

Description:
In the Linux kernel, the following vulnerability has been resolved:

scsi: core: Fix unremoved procfs host directory regression

Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name}
directory earlier") fixed a bug related to modules loading/unloading, by
adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led
to a potential duplicate call to the hostdir_rm() routine, since it's also
called from scsi_host_dev_release(). That triggered a regression report,
which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host
directory removal regression"). The fix just dropped the hostdir_rm() call
from dev_release().

But it happens that this proc directory is created on scsi_host_alloc(),
and that function "pairs" with scsi_host_dev_release(), while
scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the
reason for removing the proc directory on dev_release() was meant to cover
cases in which a SCSI host structure was allocated, but the call to
scsi_add_host() didn't happen. And that pattern happens to exist in some
error paths, for example.

Syzkaller causes that by using USB raw gadget device, error'ing on
usb-storage driver, at usb_stor_probe2(). By checking that path, we can see
that the BadDevice label leads to a scsi_host_put() after a SCSI host
allocation, but there's no call to scsi_add_host() in such path. That leads
to messages like this in dmesg (and a leak of the SCSI host proc
structure):

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+0x347/0x4e0 fs/proc/generic.c:376

The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),
but guard that with the state check for SHOST_CREATED; there is even a
comment in scsi_host_dev_release() detailing that: such conditional is
meant for cases where the SCSI host was allocated but there was no calls to
{add,remove}_host(), like the usb-storage case.

This is what we propose here and with that, the error path of usb-storage
does not trigger the warning anymore.

 References:
https://git.kernel.org/stable/c/0053f15d50d50c9312d8ab9c11e2e405812dfcac
https://git.kernel.org/stable/c/5c2386ba80e779a92ec3bb64ccadbedd88f779b1
https://git.kernel.org/stable/c/cea234bb214b17d004dfdccce4491e6ff57c96ee
https://git.kernel.org/stable/c/3678cf67ff7136db1dd3bf63c361650db5d92889
https://git.kernel.org/stable/c/d4c34782b6d7b1e68d18d9549451b19433bd4c6c
https://git.kernel.org/stable/c/e293c773c13b830cdc251f155df2254981abc320
https://git.kernel.org/stable/c/f4ff08fab66eb5c0b97e1a24edac052fb40bf5d7
https://git.kernel.org/stable/c/f23a4d6e07570826fe95023ca1aa96a011fa9f84
Copyright 2026, cxsecurity.com

 

Back to Top