CVE-2024-26918

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix active state requirement in PME polling<br /> <br /> The commit noted in fixes added a bogus requirement that runtime PM managed<br /> devices need to be in the RPM_ACTIVE state for PME polling. In fact, only<br /> devices in low power states should be polled.<br /> <br /> However there&amp;#39;s still a requirement that the device config space must be<br /> accessible, which has implications for both the current state of the polled<br /> device and the parent bridge, when present. It&amp;#39;s not sufficient to assume<br /> the bridge remains in D0 and cases have been observed where the bridge<br /> passes the D0 test, but the PM state indicates RPM_SUSPENDING and config<br /> space of the polled device becomes inaccessible during pci_pme_wakeup().<br /> <br /> Therefore, since the bridge is already effectively required to be in the<br /> RPM_ACTIVE state, formalize this in the code and elevate the PM usage count<br /> to maintain the state while polling the subordinate device.<br /> <br /> This resolves a regression reported in the bugzilla below where a<br /> Thunderbolt/USB4 hierarchy fails to scan for an attached NVMe endpoint<br /> downstream of a bridge in a D3hot power state.