Re: [PATCH v4 2/3] scsi: ufs: rpmb: Decouple device lifecycle from devres to avoid UAF

[Stanley Jhu]

On Sun, 13 Sep 2026 03:47:25 +0000, sashiko-bot@xxxxxxxxxx wrote:
> When ufs_rpmb_probe() calls scsi_device_get(), the following call chain occurs:
> ufs_rpmb_probe() -> scsi_device_get(sdev) -> try_module_get(sdev->host->hostt->module).
> Since this is called during the driver's probe sequence, and the SCSI host
> template module is likely this exact same module (ufshcd-core), it ends up
> taking a reference on itself. Because the reference won't be dropped until the
> device is released, and the device won't be released while the module is held
> active, doesn't this create a lifecycle deadlock where rmmod will permanently
> fail with -EBUSY?

The release point is not tied to module_exit, but to the glue driver's unbind
phase. Because ufshcd-core cannot be removed while a host glue driver (such as
ufshcd-pci) is active due to symbol dependencies, teardown inherently begins
with the glue driver. Unloading the glue driver initiates a hardware unbind
cascade that destroys the RPMB devices, synchronously dropping all dynamic
references on ufshcd-core. Once the glue driver finishes unloading and
relinquishes its static symbol dependency, ufshcd-core is left with zero
references and unloads cleanly.

This lifecycle was empirically verified under QEMU ARM64 with modular builds
(CONFIG_SCSI_UFSHCD=m, CONFIG_SCSI_UFSHCD_PCI=m), where the usecount comprises
both the static symbol dependency held by the glue driver (+1) and the dynamic
references acquired by the instantiated RPMB devices (+4):

  Phase                                      ufshcd_core usecount
  -----------------------------------------  --------------------
  1. insmod ufshcd-core                      0
  2. insmod ufshcd-pci (probes 4 RPMB devs)  5 (1 static symbol + 4
dynamic device)
  3. sysfs unbind 0000:00:02.0               1 (4 dynamic device refs dropped)
  4. sysfs rebind 0000:00:02.0               5 (4 dynamic device refs acquired)
  5. rmmod ufshcd_pci                        0 (RC=0; synchronous unbind)
  6. rmmod ufshcd_core                       0 (RC=0; unloaded cleanly)
  Kernel splats (KASAN, lockdep, WARN, BUG)  none

Therefore, the cyclic dependency concern raised by the analyzer is a false
positive, and the teardown sequence safely completes without deadlocks.

Thanks,
Stanley Jhu