CVE-2024-26605: PCI/ASPM: Fix deadlock when enabling ASPM
In the Linux kernel, the following vulnerability has been resolved:
PCI/ASPM: Fix deadlock when enabling ASPM
A last minute revert in 6.7-final introduced a potential deadlock when
enabling ASPM during probe of Qualcomm PCIe controllers as reported by
lockdep:
============================================
WARNING: possible recursive locking detected
6.7.0 #40 Not tainted
--------------------------------------------
kworker/u16:5/90 is trying to acquire lock:
ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pcie_aspm_pm_state_change+0x58/0xdc
but task is already holding lock:
ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(pci_bus_sem);
lock(pci_bus_sem);
*** DEADLOCK ***
Call trace:
print_deadlock_bug+0x25c/0x348
__lock_acquire+0x10a4/0x2064
lock_acquire+0x1e8/0x318
down_read+0x60/0x184
pcie_aspm_pm_state_change+0x58/0xdc
pci_set_full_power_state+0xa8/0x114
pci_set_power_state+0xc4/0x120
qcom_pcie_enable_aspm+0x1c/0x3c [pcie_qcom]
pci_walk_bus+0x64/0xbc
qcom_pcie_host_post_init_2_7_0+0x28/0x34 [pcie_qcom]
The deadlock can easily be reproduced on machines like the Lenovo ThinkPad
X13s by adding a delay to increase the race window during asynchronous
probe where another thread can take a write lock.
Add a new pci_set_power_state_locked() and associated helper functions that
can be called with the PCI bus semaphore held to avoid taking the read lock
twice.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can deadlock a system while enabling PCIe power management on some Qualcomm PCIe controller platforms. The business impact is likely availability disruption on affected hardware rather than data theft or remote compromise. Public severity data is incomplete, and the bundle does not show active exploitation.
Executive priority
Treat this as a targeted availability risk. Patch during the next kernel maintenance window, sooner for affected Qualcomm-based fleets or systems showing boot/probe instability. It does not currently justify emergency response absent local symptoms or vendor escalation.
Technical view
The bug is recursive acquisition of pci_bus_sem during ASPM enablement in Qualcomm PCIe controller probe paths. The kernel fix adds pci_set_power_state_locked() and helper paths for callers already holding the PCI bus semaphore. Reported reproduction involves Lenovo ThinkPad X13s-like systems and asynchronous probe timing.
Likely exposure
Exposure is limited to Linux systems running affected kernel versions with the relevant PCIe ASPM and Qualcomm PCIe controller path. The bundle lists affected Linux kernel lines including 6.7, 6.7.5, 6.8, 6.1.88, and 6.6.29, but distro package mapping must be verified separately.
Exploitation context
No KEV listing is present, and the provided sources do not claim exploitation in the wild. The evidence describes a race/deadlock found by lockdep and reproducible under timing changes, not an externally weaponized attack path.
Researcher notes
The source bundle lacks CVSS, CWE, and distro-specific package status. Analysis should focus on kernel lineage, stable backports, and hardware reachability of the qcom_pcie ASPM path. Do not assume broader PCIe exposure without confirming code path use.
Mitigation direction
Apply Linux vendor or distribution kernel updates containing the referenced stable fixes.
Prioritize Qualcomm PCIe controller platforms and Lenovo ThinkPad X13s-like hardware.
Track distro advisories for exact fixed package versions.
Avoid direct kernel deployment shortcuts; follow normal tested update channels.
Validation and detection
Inventory Linux kernel versions across laptops, edge devices, and ARM64 fleets.
Identify systems using Qualcomm PCIe controller drivers and ASPM.
Confirm installed kernels include the referenced stable fix commits or later vendor backports.
Review boot and kernel logs for PCIe ASPM or lockdep deadlock symptoms.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-26605 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.