Linux kernel (drivers/pci): An SR-IOV device that stops answering config reads makes the VF Resizable BAR restore path

Impact

An SR-IOV device that stops answering config reads makes the VF Resizable BAR restore path read index 7 out of a 6-entry BAR-size array, so the host kernel reads past the end of the VF's resource table and then restores BAR windows from whatever it found. The reported case is exactly the fleet shape that matters - an NVIDIA GPU that stopped responding on a power-state exit - and the vendor scores it scope-changed, meaning the bad restore reaches beyond the failing device.

Who can reach it

Host-side, on a node with SR-IOV enabled and VFs created on a device that supports VF Resizable BAR (NVIDIA GPUs among them). It fires when pci_restore_state() runs while the device is unreachable and config reads return all-ones - a wedged or power-state-stuck GPU, a link that dropped, or a device a tenant has driven into a bad state through its assigned VF. A tenant does not call it directly; a tenant that can hang its assigned device can make the host walk into it.

What to do

Boot a kernel with the sriov_restore_vf_rebar_state() error-response guard. Interim: on nodes where you do not need them, disable SR-IOV VFs (sriov_numvfs = 0) so the VF ReBAR restore path is never entered, and drain nodes whose GPUs are logging config-read failures or GC6/power-state exit errors rather than letting the recovery path run.

References