CVE-2026-90431
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A timing flaw in the Linux kernel can let an attacker cause memory errors during device removal that may crash the system or allow unauthorized access.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition between rproc_crash_handler_work() and rproc_del() allows use-after-free when a remoteproc driver is removed while crash-handler work is scheduled or executing.
Why it matters to the business
Kernel instability, crashes, or potential privilege escalation on Linux systems using remote processors, resulting in device downtime or security exposure in embedded and hardware platforms.
How an attack unfolds
An attacker with local access triggers a crash report via rproc_report_crash() while concurrently initiating device removal through rproc_del(), racing past the missing synchronization and the new deleting flag to trigger use-after-free during work execution or cancellation.
How to fix it
Apply the upstream kernel commit that introduces the deleting flag, cancels and synchronizes crash-handler work before rproc_del proceeds, and unrolls pm_stay_awake on cancellation; rebuild and deploy the patched kernel across all affected systems.
How to confirm the fix worked
Inspect kernel source for the deleting flag and synchronized cancellation logic around rproc_crash_handler_work and rproc_del; perform stress tests that concurrently report crashes and remove remoteproc devices to confirm absence of use-after-free.
Typical attack path
- Obtain local code execution on affected Linux system
- Trigger remoteproc crash report in atomic context
- Simultaneously invoke driver removal to race with scheduled crash work
- Exploit resulting use-after-free for memory corruption or denial of service
How to detect it
Search kernel logs and crash dumps for concurrent rproc_crash_handler_work and rproc_del activity, unbalanced pm_stay_awake calls, or use-after-free reports involving remoteproc structures; correlate with device removal events.
What your security team should do
- Prioritize kernel upgrade on all systems exposing remoteproc interfaces
- Review boot and hardware configurations for remote processor usage
- Monitor kernel logs for remoteproc-related crashes pending patch deployment
- Limit unprivileged local access on devices until remediation is complete
The record
In the Linux kernel, the following vulnerability has been resolved: remoteproc: Prevent crash handling to race with rproc_del() There's no synchronization between rproc_crash_handler_work() and rproc_del(), 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 RPROC_DELETE state that was introduced to ensure that "start" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the "state" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() 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 packages
| Ecosystem | Package | Introduced | Fixed |
|---|