Linux kernel (drivers/pci): When setting up an SR-IOV virtual function fails partway through, the half-initialised VF

Impact

When setting up an SR-IOV virtual function fails partway through, the half-initialised VF is left registered and is dereferenced later during removal, panicking the host. A single VF that fails to come up takes down the whole node and every tenant sitting on it, in the middle of the routine operation that hands VFs out to tenants.

Who can reach it

The trigger path is the operator's own VF provisioning - writing sriov_numvfs, which lands in sriov_enable() via the driver's sriov_configure callback (the upstream report is mlx5_core, i.e. the ConnectX fabric NIC these clusters run on). It needs host root to initiate plus a pci_setup_device() failure on one VF, so it is not directly tenant-reachable; the realistic scenario is a NIC or GPU left in a bad state by the previous tenant, or a flaky device, causing VF setup to fail during recycle and panicking the node instead of erroring out. Not applicable if SR-IOV is unused on the node.

What to do

Update to a kernel carrying the fix (no fixed_in published; take the stable commits below into your 6.1.y / 6.6.y / 6.12.y branch). Interim: reset the PF and confirm all VFs enumerate cleanly before rescheduling tenants onto a node, and drain a node before changing sriov_numvfs so a panic during reprovisioning does not take live tenants with it.

References