CVE-2024-26605

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/ASPM: Fix deadlock when enabling ASPM<br /> <br /> A last minute revert in 6.7-final introduced a potential deadlock when<br /> enabling ASPM during probe of Qualcomm PCIe controllers as reported by<br /> lockdep:<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 6.7.0 #40 Not tainted<br /> --------------------------------------------<br /> kworker/u16:5/90 is trying to acquire lock:<br /> ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pcie_aspm_pm_state_change+0x58/0xdc<br /> <br /> but task is already holding lock:<br /> ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(pci_bus_sem);<br /> lock(pci_bus_sem);<br /> <br /> *** DEADLOCK ***<br /> <br /> Call trace:<br /> print_deadlock_bug+0x25c/0x348<br /> __lock_acquire+0x10a4/0x2064<br /> lock_acquire+0x1e8/0x318<br /> down_read+0x60/0x184<br /> pcie_aspm_pm_state_change+0x58/0xdc<br /> pci_set_full_power_state+0xa8/0x114<br /> pci_set_power_state+0xc4/0x120<br /> qcom_pcie_enable_aspm+0x1c/0x3c [pcie_qcom]<br /> pci_walk_bus+0x64/0xbc<br /> qcom_pcie_host_post_init_2_7_0+0x28/0x34 [pcie_qcom]<br /> <br /> The deadlock can easily be reproduced on machines like the Lenovo ThinkPad<br /> X13s by adding a delay to increase the race window during asynchronous<br /> probe where another thread can take a write lock.<br /> <br /> Add a new pci_set_power_state_locked() and associated helper functions that<br /> can be called with the PCI bus semaphore held to avoid taking the read lock<br /> twice.