CVE-2024-26918: PCI: Fix active state requirement in PME polling
In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix active state requirement in PME polling
The commit noted in fixes added a bogus requirement that runtime PM managed
devices need to be in the RPM_ACTIVE state for PME polling. In fact, only
devices in low power states should be polled.
However there's still a requirement that the device config space must be
accessible, which has implications for both the current state of the polled
device and the parent bridge, when present. It's not sufficient to assume
the bridge remains in D0 and cases have been observed where the bridge
passes the D0 test, but the PM state indicates RPM_SUSPENDING and config
space of the polled device becomes inaccessible during pci_pme_wakeup().
Therefore, since the bridge is already effectively required to be in the
RPM_ACTIVE state, formalize this in the code and elevate the PM usage count
to maintain the state while polling the subordinate device.
This resolves a regression reported in the bugzilla below where a
Thunderbolt/USB4 hierarchy fails to scan for an attached NVMe endpoint
downstream of a bridge in a D3hot power state.
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw can make certain PCI device trees stop working correctly, causing availability impact rather than data theft. The reported scenario involved Thunderbolt/USB4 scanning failing for an attached NVMe device behind a bridge in a low-power state.
Executive priority
Treat as a moderate availability risk. Patch through normal kernel maintenance, with higher urgency for fleets using Thunderbolt/USB4 storage or workflows where device discovery failure disrupts operations.
Technical view
The bug is in Linux PCI PME polling runtime power management logic. A prior change incorrectly required polled devices to be RPM_ACTIVE and did not hold the parent bridge active while accessing subordinate config space, allowing config access failures during pci_pme_wakeup().
Likely exposure
Exposure is most likely on Linux systems running affected 6.6, 6.7, or 6.8-series kernels with PCI runtime power management, especially Thunderbolt/USB4 hierarchies and NVMe devices behind bridges.
Exploitation context
The bundle reports no CISA KEV listing and provides no evidence of active exploitation. CVSS is local, low-complexity, no-privilege, no-user-interaction, with high availability impact and no confidentiality or integrity impact.
Researcher notes
The source describes a regression fix, not a memory corruption issue. The critical condition is maintaining parent bridge RPM_ACTIVE state while PME polling subordinate devices whose config space must remain accessible.
Mitigation direction
Apply Linux kernel updates containing the referenced stable fixes.
Use distribution vendor advisories to map package versions to fixed kernels.
Prioritize systems using Thunderbolt/USB4 or removable PCIe storage paths.
If updates are delayed, monitor vendor guidance for safe temporary workarounds.
Validation and detection
Inventory Linux kernel versions and identify affected 6.6, 6.7, or 6.8 deployments.
Confirm whether hosts use PCI runtime power management and Thunderbolt/USB4 device chains.
Check distribution changelogs for the referenced PCI PME polling fix.
Review kernel logs for PCI config access or device scan failures.
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-26918 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.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.