CVE-2024-35809 is a medium-severity vulnerability in the Linux kernel affecting the PCI runtime power management (PM) subsystem, specifically within the rtsx_pcr PCI driver. The issue arises from a race condition between the .runtime_idle() callback and the .remove() callback during driver removal. The .runtime_idle() callback is intended to be invoked when the device is idle, while .remove() is called when the driver is being removed. The vulnerability occurs because pm_runtime_get_sync(), which is called before driver removal to synchronize runtime PM state, does not guarantee that any already running .runtime_idle() callbacks have completed. If a .runtime_idle() callback is running concurrently, this can lead to a kernel crash caused by an unhandled page fault. This is due to the fact that pm_runtime_get_sync() returns immediately if the device runtime PM status is RPM_ACTIVE, without waiting for the .runtime_idle() callback to finish. The root cause is that .runtime_idle() can still be executing after pm_runtime_get_sync() returns, and the driver removal code does not protect against this concurrency. The recommended fix involves calling pm_runtime_barrier() after pm_runtime_get_sync() in pci_device_remove(), which waits for any ongoing .runtime_idle() callbacks to complete before proceeding with driver removal. This approach prevents the race condition not only in the rtsx_pcr driver but also in any PCI drivers that implement .runtime_idle() callbacks. The vulnerability does not affect confidentiality or integrity but impacts availability by causing kernel crashes. Exploitation requires local privileges (PR:L), no user interaction (UI:N), and has low attack vector scope (AV:L), meaning an attacker must have local access to the system. The CVSS 3.1 base score is 5.5 (medium severity), reflecting the potential for denial of service via kernel crash but limited exploitability and impact scope.

For European organizations, this vulnerability poses a risk primarily to systems running vulnerable Linux kernel versions with the affected rtsx_pcr PCI driver or other PCI drivers using .runtime_idle() callbacks without proper synchronization. The impact is a potential denial of service through kernel crashes, which can disrupt critical services, especially in environments relying on Linux servers for infrastructure, industrial control, or embedded systems. Organizations in sectors such as telecommunications, manufacturing, finance, and public administration that use Linux-based systems with PCI devices may experience system instability or outages. Although the vulnerability does not allow privilege escalation or data compromise directly, repeated crashes could lead to operational downtime and increased maintenance costs. Given that exploitation requires local access, the threat is more significant in environments where untrusted users have shell or physical access, such as shared hosting, multi-tenant cloud environments, or poorly secured endpoints. The vulnerability could also be leveraged as part of a multi-stage attack to cause disruption or cover tracks by crashing systems.

European organizations should ensure that Linux kernel versions are updated to include the patch that calls pm_runtime_barrier() after pm_runtime_get_sync() in pci_device_remove(), thereby eliminating the race condition. System administrators should: 1) Apply the latest Linux kernel updates from trusted sources promptly, especially for kernels used in production environments. 2) Audit PCI drivers in use, particularly rtsx_pcr and others implementing .runtime_idle() callbacks, to verify if they have incorporated the recommended synchronization fix. 3) Limit local access to critical Linux systems by enforcing strict access controls, using multi-factor authentication, and monitoring for unauthorized login attempts. 4) Implement kernel crash monitoring and automated recovery mechanisms to reduce downtime in case of unexpected crashes. 5) For environments where patching is delayed, consider disabling runtime power management features for affected devices as a temporary workaround, understanding the trade-offs in power consumption. 6) Engage with Linux distribution vendors or maintainers to confirm that the fix is included in their kernel packages and backported to supported versions.