CVE-2024-26935

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Fix unremoved procfs host directory regression<br /> <br /> Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name}<br /> directory earlier") fixed a bug related to modules loading/unloading, by<br /> adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led<br /> to a potential duplicate call to the hostdir_rm() routine, since it&amp;#39;s also<br /> called from scsi_host_dev_release(). That triggered a regression report,<br /> which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host<br /> directory removal regression"). The fix just dropped the hostdir_rm() call<br /> from dev_release().<br /> <br /> But it happens that this proc directory is created on scsi_host_alloc(),<br /> and that function "pairs" with scsi_host_dev_release(), while<br /> scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the<br /> reason for removing the proc directory on dev_release() was meant to cover<br /> cases in which a SCSI host structure was allocated, but the call to<br /> scsi_add_host() didn&amp;#39;t happen. And that pattern happens to exist in some<br /> error paths, for example.<br /> <br /> Syzkaller causes that by using USB raw gadget device, error&amp;#39;ing on<br /> usb-storage driver, at usb_stor_probe2(). By checking that path, we can see<br /> that the BadDevice label leads to a scsi_host_put() after a SCSI host<br /> allocation, but there&amp;#39;s no call to scsi_add_host() in such path. That leads<br /> to messages like this in dmesg (and a leak of the SCSI host proc<br /> structure):<br /> <br /> usb-storage 4-1:87.51: USB Mass Storage device detected<br /> proc_dir_entry &amp;#39;scsi/usb-storage&amp;#39; already registered<br /> WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376<br /> <br /> The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),<br /> but guard that with the state check for SHOST_CREATED; there is even a<br /> comment in scsi_host_dev_release() detailing that: such conditional is<br /> meant for cases where the SCSI host was allocated but there was no calls to<br /> {add,remove}_host(), like the usb-storage case.<br /> <br /> This is what we propose here and with that, the error path of usb-storage<br /> does not trigger the warning anymore.