PCI/ASPM: Fix link state exit during switch upstream function removal
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux | unaffected |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linux | Linux | affected |
|
Configuration 1 [-]
|
No data.
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux Kernel | — |
| Source | ID | Title |
|---|---|---|
EUVD |
EUVD-2025-11276 | In the Linux kernel, the following vulnerability has been resolved: PCI/ASPM: Fix link state exit during switch upstream function removal Before 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free"), we would free the ASPM link only after the last function on the bus pertaining to the given link was removed. That was too late. If function 0 is removed before sibling function, link->downstream would point to free'd memory after. After above change, we freed the ASPM parent link state upon any function removal on the bus pertaining to a given link. That is too early. If the link is to a PCIe switch with MFD on the upstream port, then removing functions other than 0 first would free a link which still remains parent_link to the remaining downstream ports. The resulting GPFs are especially frequent during hot-unplug, because pciehp removes devices on the link bus in reverse order. On that switch, function 0 is the virtual P2P bridge to the internal bus. Free exactly when function 0 is removed -- before the parent link is obsolete, but after all subordinate links are gone. [kwilczynski: commit log] |
Ubuntu USN |
USN-7585-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7585-2 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-7585-3 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-7585-4 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7585-5 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-7585-6 | Linux kernel (BlueField) vulnerabilities |
Ubuntu USN |
USN-7585-7 | Linux kernel (Raspberry Pi) vulnerabilities |
Ubuntu USN |
USN-7591-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7591-2 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-7591-3 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-7591-4 | Linux kernel (AWS) vulnerabilities |
Ubuntu USN |
USN-7591-5 | Linux kernel (Intel IoTG) vulnerabilities |
Ubuntu USN |
USN-7591-6 | Linux kernel (Raspberry Pi) vulnerabilities |
Ubuntu USN |
USN-7592-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7593-1 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-7594-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7594-2 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7594-3 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7597-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7597-2 | Linux kernel (Azure FIPS) vulnerabilities |
Ubuntu USN |
USN-7598-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7602-1 | Linux kernel (Xilinx ZynqMP) vulnerabilities |
Ubuntu USN |
USN-7605-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7605-2 | Linux kernel (Low Latency) vulnerabilities |
Ubuntu USN |
USN-7606-1 | Linux kernel (OEM) vulnerabilities |
Ubuntu USN |
USN-7628-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7640-1 | Linux kernel (IoT) vulnerabilities |
Ubuntu USN |
USN-7655-1 | Linux kernel (Intel IoTG) vulnerabilities |
Ubuntu USN |
USN-7703-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7703-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7703-3 | Linux kernel (Oracle) vulnerabilities |
Ubuntu USN |
USN-7703-4 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7719-1 | Linux kernel (Raspberry Pi Real-time) vulnerabilities |
Ubuntu USN |
USN-7737-1 | Linux kernel (Azure) vulnerabilities |
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.236% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-416 | |
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Metrics |
cvssV3_1
|
cvssV3_1
|
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-20 |
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: PCI/ASPM: Fix link state exit during switch upstream function removal Before 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free"), we would free the ASPM link only after the last function on the bus pertaining to the given link was removed. That was too late. If function 0 is removed before sibling function, link->downstream would point to free'd memory after. After above change, we freed the ASPM parent link state upon any function removal on the bus pertaining to a given link. That is too early. If the link is to a PCIe switch with MFD on the upstream port, then removing functions other than 0 first would free a link which still remains parent_link to the remaining downstream ports. The resulting GPFs are especially frequent during hot-unplug, because pciehp removes devices on the link bus in reverse order. On that switch, function 0 is the virtual P2P bridge to the internal bus. Free exactly when function 0 is removed -- before the parent link is obsolete, but after all subordinate links are gone. [kwilczynski: commit log] | |
| Title | PCI/ASPM: Fix link state exit during switch upstream function removal | |
| References |
|