CVE-2026-92506
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A timing flaw in how the Linux kernel handles removal of certain hardware-control drivers could let a local attacker crash the whole system.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Concurrent unregistration of SCMI protocol drivers can trigger a use-after-free on a list head that was freed while a notifier callback was executing outside the mutex, resulting in a double-free or invalid memory access within the kernel.
Why it matters to the business
Systems running affected kernels may experience crashes, memory corruption, or denial of service; the low exploitation probability and absence from known campaigns limit immediate operational disruption for most deployments.
How an attack unfolds
An attacker with local access loads or unloads multiple SCMI protocol drivers in rapid succession, forcing two threads to race through the unrequest path; one thread frees the list head while the other holds a stale reference, leading to a crash or potential memory corruption upon reacquiring the lock.
How to fix it
Upgrade to a Linux kernel version that includes the fix for the race in scmi_protocol_device_unrequest by ensuring list and IDR updates complete before dropping the mutex; apply the stable or distribution backport when available.
How to confirm the fix worked
Confirm the presence of the upstream commit that moves list-head freeing inside the critical section and verify that concurrent driver unregistration no longer produces list corruption under stress testing.
Typical attack path
- Obtain local code execution or module-loading privileges on a Linux system using the SCMI firmware interface.
- Trigger concurrent unregistration of two SCMI drivers for the same protocol.
- Cause the race window that frees the list head during a notifier callback.
- Trigger dereference of the freed structure to induce kernel panic or corruption.
How to detect it
Review kernel logs for oops or panic messages referencing scmi_protocol_device_unrequest or list corruption during driver unload; correlate with audit logs showing rapid concurrent SCMI driver unregistrations.
What your security team should do
- Prioritize kernel updates on systems exposing the SCMI interface (embedded, servers with ARM management controllers).
- Monitor vendor advisories for backported fixes in distribution kernels.
- Limit unprivileged module loading where feasible until patched.
The record
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix requested device removal race scmi_protocol_device_unrequest() drops scmi_requested_devices_mtx while notifying listeners but continues to retain the per-protocol list head. When two SCMI drivers for the same protocol unregister concurrently, one thread can remove the final request and free the list head while the other is running its notifier. The latter then dereferences the freed list head after reacquiring the mutex and can free it a second time. Complete the list and IDR updates, including freeing an empty list head, before dropping the mutex. Keep the blocking notifier outside the critical section and retain only the detached request across the callback.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|