CVE-2024-53194: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2024-53194

In the Linux kernel, the following vulnerability has been resolved: PCI: Fix use-after-free of slot->bus on hot remove Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock. Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot firmware"), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver. The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router's Root Port and thus causes hot removal of the dock. The crash occurs when pciehp is unbound from one of the dock's Downstream Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The pci_slot contains a pointer to the pci_bus below the Downstream Port, but a reference on that pci_bus is never acquired. The pci_bus is destroyed before the pci_slot, so a use-after-free ensues when pci_slot_release() accesses slot->bus. In principle this should not happen because pci_stop_bus_device() unbinds pciehp (and therefore destroys the pci_slot) before the pci_bus is destroyed by pci_remove_bus_device(). However the stacktrace provided by Dennis shows that pciehp is unbound from pci_remove_bus_device() instead of pci_stop_bus_device(). To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy: It first unbinds all drivers in the sub-hierarchy in pci_stop_bus_device() and then actually removes the devices in pci_remove_bus_device(). There is no precaution to prevent driver binding in-between pci_stop_bus_device() and pci_remove_bus_device(). In Dennis' case, it seems removal of the hierarchy by pciehp races with driver binding by pci_bus_add_devices(). pciehp is bound to the Downstream Port after pci_stop_bus_device() has run, so it is unbound by pci_remove_bus_device() instead of pci_stop_bus_device(). Because the pci_bus has already been destroyed at that point, accesses to it result in a use-after-free. One might conclude that driver binding needs to be prevented after pci_stop_bus_device() has run. However it seems risky that pci_slot points to pci_bus without holding a reference. Solely relying on correct ordering of driver unbind versus pci_bus destruction is certainly not defensive programming. If pci_slot has a need to access data in pci_bus, it ought to acquire a reference. Amend pci_create_slot() accordingly. Dennis reports that the crash is not reproducible with this change. Abridged stacktrace: pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:dev_driver_string+0x12/0x40 pci_destroy_slot pciehp_remove pcie_port_remove_service device_release_driver_internal bus_remove_device device_del device_unregister remove_iter device_for_each_child pcie_portdrv_remove pci_device_remove device_release_driver_internal bus_remove_device device_del pci_remove_bus_device (recursive invocation) pci_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist

AI Analysis

Technical Summary

CVE-2024-53194 is a high-severity use-after-free vulnerability in the Linux kernel's PCI hotplug (pciehp) driver, specifically triggered during the hot removal of USB4 docks on certain hardware configurations such as recent Lenovo laptops. The root cause lies in improper lifecycle management of pci_slot and pci_bus objects within the PCI subsystem. When the thunderbolt driver resets USB4 host routers during probe, it causes hot removal events on the dock's downstream ports. The pciehp driver creates a pci_slot structure on binding and destroys it on unbinding, with pci_slot containing a pointer to a pci_bus object. However, the pci_bus reference is not properly acquired, leading to a use-after-free condition when pci_slot_release() accesses slot->bus after the pci_bus has already been destroyed. This occurs because the unbinding of pciehp happens during pci_remove_bus_device() instead of pci_stop_bus_device(), breaking the expected order of driver unbind and bus destruction. A race condition between driver binding and removal exacerbates this issue. The vulnerability can cause kernel crashes (general protection faults) and potentially lead to system instability or denial of service. The fix involves amending pci_create_slot() to acquire a reference to pci_bus, preventing premature destruction and use-after-free. This vulnerability is tracked under CWE-416 (Use After Free) and has a CVSS v3.1 score of 7.8, indicating high severity with impacts on confidentiality, integrity, and availability. No known exploits are currently reported in the wild.

Potential Impact

For European organizations, this vulnerability poses a significant risk primarily to systems running vulnerable Linux kernel versions on hardware platforms that utilize USB4 docks and Thunderbolt interfaces, such as Lenovo laptops prevalent in enterprise environments. The use-after-free can cause kernel crashes leading to denial of service, disrupting critical business operations, especially in sectors relying on stable Linux-based infrastructure (e.g., finance, manufacturing, research). Furthermore, the vulnerability's potential to impact confidentiality and integrity arises from the possibility of arbitrary code execution or privilege escalation if exploited beyond crashing the system, although no public exploits are known yet. Organizations with remote or automated management of Linux systems may face increased risk if attackers can trigger hotplug events remotely or via malicious USB devices. The complexity of the vulnerability and its hardware dependency may limit widespread exploitation but targeted attacks against high-value assets remain a concern.

Mitigation Recommendations

1. Apply the official Linux kernel patches that address CVE-2024-53194 as soon as they become available from trusted sources or Linux distribution vendors. 2. For environments using Lenovo laptops or similar hardware with USB4 docks, temporarily avoid hot removal or insertion of USB4 devices until patched. 3. Implement strict device control policies to limit unauthorized USB device connections, reducing attack surface. 4. Monitor kernel logs for pciehp-related errors or crashes indicative of exploitation attempts. 5. Employ kernel live patching solutions where feasible to minimize downtime during patch deployment. 6. Coordinate with hardware vendors to ensure firmware and Thunderbolt driver updates are applied, as they interact closely with the affected kernel components. 7. For critical systems, consider isolating or segmenting Linux hosts with vulnerable kernels to limit exposure. 8. Educate system administrators on the risks of hotplug events and encourage controlled hardware changes in production environments.