Linux kernel (drivers/pci): Pci_bus_lock() locked every device on the bus except the bridge itself, so a secondary bus

CVSS 7.8CVE-2024-46750Kernel, userspace & hypervisorcurated

Impact

Pci_bus_lock() locked every device on the bus except the bridge itself, so a secondary bus reset gets issued while config-space access to that bridge is still unblocked. Config reads and writes race against a live link reset, which means device state can be read or written mid-reset and left inconsistent - the CNA rated this high on confidentiality AND integrity, not just availability.

Who can reach it

A tenant container or VM holding /dev/vfio/* can drive the reset half of this itself: VFIO exposes device and bus reset to userspace (VFIO_DEVICE_RESET / VFIO_DEVICE_PCI_HOT_RESET), and those paths land in the pci_reset_bus() / pci_bus_lock() code that is missing the bridge lock. The upstream report came from vmd_probe() issuing an unlocked secondary bus reset. No host root is required for the tenant side once the device node is in the container; the exposure is real on any node where GPUs or NICs are passed through with VFIO.

What to do

Update to a kernel carrying the fix (no fixed_in published; the stable commits below are backported into 6.1.y and 6.6.y). Interim: do not grant tenants VFIO groups that share a bridge with another tenant's device, and verify each passthrough device sits in its own IOMMU group behind its own downstream port before handing the node out.

References

https://git.kernel.org/stable/c/0790b89c7e911003b8c50ae50e3ac7645de1fae9 https://git.kernel.org/stable/c/df77a678c33871a6e4ac5b54a71662f1d702335b https://nvd.nist.gov/vuln/detail/CVE-2024-46750

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.