Linux kernel (drivers/pci/hotplug): Removing nested PCIe hotplug ports can deadlock - a parent hotplug port holds the

CVSS 5.5CVE-2025-37843Kernel, userspace & hypervisorcurated

Impact

Removing nested PCIe hotplug ports can deadlock - a parent hotplug port holds the global PCI rescan/remove lock while waiting for the child port's driver to unbind, and the child then blocks trying to take the same lock. Nothing breaks the cycle: PCI enumeration and removal are wedged host-wide from that point on, so no device can be added, removed or reprovisioned until the node reboots.

Who can reach it

Device-driven. The lock cycle lives in the nested hotplug removal path, which is the topology of any GPU or NVMe chassis where hotplug-capable downstream ports sit behind another hotplug port. The upstream commit only reduces the frequency - it removes a device-replacement check that fired on plain removal too, and notes a proper fix is still being worked on. The reported reproducer is device removal during system sleep with Thunderbolt, which does not apply to a server that never suspends; the underlying long-standing race does, and it needs no tenant privilege, just a removal event in a nested hotplug hierarchy.

What to do

Update to a kernel carrying the fix (no fixed_in published; stable commits below) understanding it narrows rather than closes the race. Interim: drain the node before any removal under a nested hotplug hierarchy, and avoid concurrent removals of parent and child hotplug ports.

References

https://git.kernel.org/stable/c/e4a1d7defbc2d806540720a5adebe24ec3488683 https://git.kernel.org/stable/c/0d0bbd01f7c0ac7d1be9f85aaf2cd0baec34655f https://nvd.nist.gov/vuln/detail/CVE-2025-37843

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.