CVE-2026-90431: remoteproc: Prevent crash handling to race with rproc_del()
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: Prevent crash handling to race with rprocdel()
There's no synchronization between rproccrashhandlerwork() and rprocdel(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues.
To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds.
In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a "deleting" flag is introduced. This is similar to the RPROCDELETE state that was introduced to ensure that "start" didn't race with rprocdel(), but the existing mechanism can not be used as it's valid to call rprocreportcrash() in atomic context - and the "state" is protected by a mutex.
In the event that work is cancelled the pmstayawake() is left unbalanced and need to be unrolled.
The blocking and cancelling of crash-handler work prior to the actual rprocshutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel remoteproc subsystem are exposed when a remote processor driver can be removed while crash-handler work is scheduled or executing. The vulnerable condition is the race between crash handling and rproc_del().
What condition is required to trigger the use-after-free?
A remote processor crash must be reported such that crash-handler work is scheduled or running, while the associated remoteproc driver is being removed. The concurrent removal can free resources still used by the crash-handler work.
What is the mitigation if the fix cannot be applied immediately?
The provided data does not specify an operational workaround. The documented fix prevents new crash handling during deletion and cancels and synchronizes pending crash-handler work before removal proceeds.
How does the fix affect crash reporting during shutdown?
Crashes caused during rproc_shutdown() will not enter the crash-handling path and therefore will not generate the associated crash-handling events. This is an explicit consequence of blocking and cancelling crash-handler work before shutdown.