Linux kernel (drivers/pci): Pci_dev_lock() and the sysfs SR-IOV path took the device lock and the config-space access

CVSS 5.9CVE-2022-49434Kernel, userspace & hypervisorcurated

Impact

Pci_dev_lock() and the sysfs SR-IOV path took the device lock and the config-space access lock in opposite orders, so a device reset racing an SR-IOV VF enable/disable deadlocks permanently. Both threads hang in D state holding the PCI device lock, which wedges every subsequent operation on that device - VF provisioning, reset, unbind - and the only way out is a reboot of the node all the tenants are sharing.

Who can reach it

Both halves are reachable in a normal passthrough cluster. A tenant holding /dev/vfio/* can call VFIO_DEVICE_RESET, which goes through pci_dev_lock() - that is side A and needs no host privilege. Side B is the operator's own VF lifecycle: writing to sysfs sriov_numvfs to hand out or reclaim VFs, which reaches pci_cfg_access_lock() through vfio_pci_core_sriov_configure() and pci_disable_sriov(). A tenant that resets its device in a loop while the control plane is reprovisioning VFs on the same PF can win the interleaving. Requires SR-IOV to be in use on the node.

What to do

Update to a kernel carrying the fix (no fixed_in published by the CNA; the stable commits below are widely backported). Interim: serialise VF provisioning against tenant activity - stop the tenant workload and revoke the VFIO device node before changing sriov_numvfs on a PF, rather than reconfiguring VFs while tenants are live on the same PF.

References

https://git.kernel.org/stable/c/c3c6dc1853b8bf3c718f96fd8480a6eb09ba4831 https://git.kernel.org/stable/c/aed6d4d519210c28817948f34c53b6e058e0456c https://nvd.nist.gov/vuln/detail/CVE-2022-49434

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.