CVE-2024-35809

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/PM: Drain runtime-idle callbacks before driver removal<br /> <br /> A race condition between the .runtime_idle() callback and the .remove()<br /> callback in the rtsx_pcr PCI driver leads to a kernel crash due to an<br /> unhandled page fault [1].<br /> <br /> The problem is that rtsx_pci_runtime_idle() is not expected to be running<br /> after pm_runtime_get_sync() has been called, but the latter doesn&amp;#39;t really<br /> guarantee that. It only guarantees that the suspend and resume callbacks<br /> will not be running when it returns.<br /> <br /> However, if a .runtime_idle() callback is already running when<br /> pm_runtime_get_sync() is called, the latter will notice that the runtime PM<br /> status of the device is RPM_ACTIVE and it will return right away without<br /> waiting for the former to complete. In fact, it cannot wait for<br /> .runtime_idle() to complete because it may be called from that callback (it<br /> arguably does not make much sense to do that, but it is not strictly<br /> prohibited).<br /> <br /> Thus in general, whoever is providing a .runtime_idle() callback needs<br /> to protect it from running in parallel with whatever code runs after<br /> pm_runtime_get_sync(). [Note that .runtime_idle() will not start after<br /> pm_runtime_get_sync() has returned, but it may continue running then if it<br /> has started earlier.]<br /> <br /> One way to address that race condition is to call pm_runtime_barrier()<br /> after pm_runtime_get_sync() (not before it, because a nonzero value of the<br /> runtime PM usage counter is necessary to prevent runtime PM callbacks from<br /> being invoked) to wait for the .runtime_idle() callback to complete should<br /> it be running at that point. A suitable place for doing that is in<br /> pci_device_remove() which calls pm_runtime_get_sync() before removing the<br /> driver, so it may as well call pm_runtime_barrier() subsequently, which<br /> will prevent the race in question from occurring, not just in the rtsx_pcr<br /> driver, but in any PCI drivers providing .runtime_idle() callbacks.