Linux kernel (drivers/pci): Tearing down a PF that still has SR-IOV VFs takes pci_rescan_remove_lock recursively and

Impact

Tearing down a PF that still has SR-IOV VFs takes pci_rescan_remove_lock recursively and deadlocks. The thread wedges holding the global PCI rescan/remove lock, so every subsequent PCI enumeration, device bind, VF create and hot-remove on that node blocks behind it forever - the node stops being able to hand devices to anyone, and only a reboot clears it.

Who can reach it

Host-side, needs the ability to write PCI sysfs (root, or a privileged container with writable /sys) on a node with SR-IOV VFs created - the mlx5 trace in the report is a NIC, and the same shape applies to any PF that calls sriov_disable() from its remove path. The trigger is the ordinary fleet operation of removing a PF that still has VFs (echo 1 > .../remove after sriov_numvfs), which is exactly what VF-reclaim and node-reimage automation does between tenants, so this fires from your own control plane as readily as from an attacker.

What to do

Update to 5.10.252 / 5.15.202 / 6.1.165 / 6.6.128 / 6.12.75 / 6.18 or later (the offending rescan-remove locking commit is reverted). Interim: always set sriov_numvfs to 0 and let VF teardown complete before removing or unbinding a PF, and keep PCI sysfs unwritable from containers.

References