// For flags

CVE-2024-26918

PCI: Fix active state requirement in PME polling

Severity Score

"-"
*CVSS v-

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

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.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: PCI: corrige el requisito de estado activo en el sondeo de PME. La confirmación observada en las correcciones agregó un requisito falso de que los dispositivos administrados por PM en tiempo de ejecución deben estar en el estado RPM_ACTIVE para el sondeo de PME. De hecho, sólo se deben sondear los dispositivos en estados de bajo consumo de energía. Sin embargo, todavía existe el requisito de que se pueda acceder al espacio de configuración del dispositivo, lo que tiene implicaciones tanto para el estado actual del dispositivo sondeado como para el puente principal, cuando esté presente. No es suficiente asumir que el puente permanece en D0 y se han observado casos en los que el puente pasa la prueba D0, pero el estado PM indica RPM_SUSPENDING y el espacio de configuración del dispositivo sondeado se vuelve inaccesible durante pci_pme_wakeup(). Por lo tanto, dado que ya se requiere que el puente esté en el estado RPM_ACTIVE, formalice esto en el código y eleve el recuento de uso de PM para mantener el estado mientras se sondea el dispositivo subordinado. Esto resuelve una regresión reportada en el bugzilla a continuación donde una jerarquía Thunderbolt/USB4 no puede buscar un endpoint NVMe conectado aguas abajo de un puente en un estado de energía D3hot.

*Credits: N/A
CVSS Scores
Attack Vector
-
Attack Complexity
-
Privileges Required
-
User Interaction
-
Scope
-
Confidentiality
-
Integrity
-
Availability
-
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-02-19 CVE Reserved
  • 2024-04-17 CVE Published
  • 2024-04-18 EPSS Updated
  • 2024-08-02 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.6 < 6.6.18
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.6 < 6.6.18"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.6 < 6.7.6
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.6 < 6.7.6"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.6 < 6.8
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.6 < 6.8"
en
Affected