CVE-2024-26605

PCI/ASPM: Fix deadlock when enabling ASPM

published February 24, 2024

CVSS
—
EPSS
0%
Percentile
10.3
In the wild
Unconfirmed
What it is

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.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00208 · 10.3th percentile
Published
2024-02-24T15:17Z
EPSS history
Timeline
  • 24 FEB 15:17Z
    PCI/ASPM: Fix deadlock when enabling ASPM
    cvelistv5