CVE-2024-26935

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.