Linux kernel (drivers/pci): The PCI slot-lock failure path releases a lock the caller never took, which at best warns

Impact

The PCI slot-lock failure path releases a lock the caller never took, which at best warns and at worst drops a lock another thread is holding. That thread then runs its slot reset with no serialisation against a second reset or a rescan on the same slot - concurrent unsynchronised reset of shared PCI hierarchy state on a node several tenants are sitting on.

Who can reach it

Local, and reachable from device passthrough: slot-level reset is what a tenant VM triggers through VFIO_DEVICE_PCI_HOT_RESET on /dev/vfio/*, and the racing trylock failure is exactly what you get when two callers contend for the same slot. So two tenants whose devices sit under the same bridge, or one tenant looping resets on its assigned GPU, can drive it. Also reachable by host root through the sysfs reset attributes. A container with no /dev/vfio/* and no PCI sysfs write access cannot reach it.

What to do

Update to 5.10.252 / 5.15.202 / 6.1.165 / 6.6.128 or later (also fixed in 6.11+ and 4.20/5.5 lines). Interim: stop granting VFIO hot-reset-capable device access to untrusted tenants, and make sure passthrough devices are in single-device IOMMU groups so a tenant reset cannot contend on a slot shared with another tenant.

References