Linux kernel (drivers/pci): Enabling or disabling SR-IOV virtual functions was not serialised against PCI hotplug, so

Impact

Enabling or disabling SR-IOV virtual functions was not serialised against PCI hotplug, so VF add/remove can run concurrently with the same devices being torn down by a hotplug event. Two paths mutate the same device list at once - the outcome is corrupted PCI device state and a crash on the node whose VFs are being handed out or reclaimed. The earlier attempt to fix this deadlocked on PF removal and had to be reverted, so systems have been carrying the race for a while.

Who can reach it

The VF half is the operator's own tenant-provisioning path: writing sysfs sriov_numvfs to create or destroy the VFs assigned to tenant VMs. The hotplug half is device- or firmware-driven and does not need a human - a link event, a surprise removal, or a DPC/AER-driven re-enumeration on the same hierarchy supplies it. Requires SR-IOV in use, which is the norm on any node handing out VFs of a ConnectX-class NIC or a virtualised GPU. Not directly tenant-triggerable, but a tenant that can induce link or error events on its own passthrough device improves the odds.

What to do

Update to a kernel carrying the fix (no fixed_in published; stable commits below). Interim: serialise VF provisioning in your control plane so sriov_numvfs writes never overlap hotplug activity on the same root port, and drain the node before reprovisioning VFs.

References