CVE-2024-26935: scsi: core: Fix unremoved procfs host directory regression

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/${procname} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsiprochostdirrm() on scsiremovehost(). But that led to a potential duplicate call to the hostdirrm() routine, since it's also called from scsihostdevrelease(). 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 hostdirrm() call from devrelease().

But it happens that this proc directory is created on scsihostalloc(), and that function "pairs" with scsihostdevrelease(), while scsiremovehost() pairs with scsiaddhost(). In other words, it seems the reason for removing the proc directory on devrelease() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsiaddhost() 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 usbstorprobe2(). By checking that path, we can see that the BadDevice label leads to a scsihostput() after a SCSI host allocation, but there's no call to scsiaddhost() 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 procdirentry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 procregister+0x347/0x4e0 fs/proc/generic.c:376

The proper fix seems to still call scsiprochostdirrm() on devrelease(), but guard that with the state check for SHOSTCREATED; there is even a comment in scsihostdevrelease() 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.