Linux kernel (drivers/pci): Pci_device_is_present() read the Vendor/Device ID directly, which always reads as all-ones

Impact

Pci_device_is_present() read the Vendor/Device ID directly, which always reads as all-ones on a virtual function, so the kernel concluded every VF was absent. Drivers acted on that false answer - the reported case marks the device broken and drops the completion that would have finished in-flight I/O, wedging the request queue permanently. The practical consequence is a stuck VF teardown, not memory corruption: the process disabling VFs hangs unkillably in D state and the VF's resources cannot be reclaimed.

Who can reach it

PF/VF state confusion in core PCI code, so it applies wherever VFs exist - which in a GPU cloud is the mechanism for handing a slice of a NIC or GPU to a tenant. The hang is hit on the operator's reclaim path (unbinding a VF driver, or writing 0 to sriov_numvfs) while I/O is still in flight, and a tenant keeping its device continuously busy makes that the normal case rather than a rare race. Requires SR-IOV in use; no tenant privilege is needed to keep I/O outstanding.

What to do

Update to a kernel carrying the fix (no fixed_in published; stable commits below). Interim: quiesce and stop the tenant workload, then confirm the VF is idle, before unbinding its driver or reducing sriov_numvfs - do not tear down VFs under live I/O.

References