2.2 KiB
CVE-2024-42302
Description
In the Linux kernel, the following vulnerability has been resolved:PCI/DPC: Fix use-after-free on concurrent DPC and hot-removalKeith reports a use-after-free when a DPC event occurs concurrently tohot-removal of the same portion of the hierarchy:The dpc_handler() awaits readiness of the secondary bus below theDownstream Port where the DPC event occurred. To do so, it polls theconfig space of the first child device on the secondary bus. If thatchild device is concurrently removed, accesses to its struct pci_devcause the kernel to oops.That's because pci_bridge_wait_for_secondary_bus() neglects to hold areference on the child device. Before v6.3, the function was onlycalled on resume from system sleep or on runtime resume. Holding areference wasn't necessary back then because the pciehp IRQ threadcould never run concurrently. (On resume from system sleep, IRQs arenot enabled until after the resume_noirq phase. And runtime resume isalways awaited before a PCI device is removed.)However starting with v6.3, pci_bridge_wait_for_secondary_bus() is alsocalled on a DPC event. Commit 53b54ad074de ("PCI/DPC: Await readinessof secondary bus after reset"), which introduced that, failed toappreciate that pci_bridge_wait_for_secondary_bus() now needs to hold areference on the child device because dpc_handler() and pciehp mayindeed run concurrently. The commit was backported to v5.10+ stablekernels, so that's the oldest one affected.Add the missing reference acquisition.Abridged stack trace: BUG: unable to handle page fault for address: 00000000091400c0 CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0 RIP: pci_bus_read_config_dword+0x17/0x50 pci_dev_wait() pci_bridge_wait_for_secondary_bus() dpc_reset_link() pcie_do_recovery() dpc_handler()
POC
Reference
No PoCs from references.