Cloudanix VulnDB

CVE-2026-93086

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's cleanup of hardware communication channels could let an attacker crash the entire system.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

The scmi_cleanup_channels() function invokes idr_for_each() on TX/RX channel IDRs while the destroy callback removes the current entry, invalidating the radix-tree iterator; the callback cannot be RCU-protected because device destruction may sleep, leaving the IDR in an inconsistent state until idr_destroy() runs.

Why it matters to the business

Kernel panic or memory corruption during SCMI transport teardown can cause denial of service on affected Linux systems, requiring reboots and potentially disrupting hardware management on servers, embedded devices, and cloud instances.

How an attack unfolds

An attacker with local access triggers repeated SCMI channel allocation and cleanup operations (for example via crafted firmware or driver unload sequences) to race the IDR walk against the removal callback, corrupting iterator state and inducing a kernel crash or exploitable memory error.

How to fix it

Update the Linux kernel to a version containing the upstream fix that removes IDR entries from the destroy callback and lets idr_destroy() perform teardown; rebuild and reboot all affected systems.

How to confirm the fix worked

Inspect the arm_scmi driver source for the updated scmi_cleanup_channels() implementation that omits IDR removal inside the idr_for_each() callback; verify the patch commit is present in the running kernel tree.

Typical attack path

  1. Obtain local code execution on the target system
  2. Trigger SCMI transport channel creation and subsequent cleanup paths
  3. Force concurrent idr_for_each() walk and entry removal from the destroy callback
  4. Induce iterator invalidation leading to kernel panic or memory corruption

How to detect it

Review kernel logs for oops or panic messages referencing idr_for_each, scmi_cleanup_channels, or arm_scmi device destruction; examine crash dumps for radix-tree iterator corruption during IDR walks.

What your security team should do

  • Prioritize kernel upgrades on all systems exposing SCMI transports within the next maintenance window
  • Monitor upstream stable and distribution kernels for the merged fix
  • Restrict local unprivileged access on high-value systems until patched

The record

In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Avoid IDR updates while cleaning channels scmi_cleanup_channels() walks the TX/RX channel IDRs with idr_for_each() to free transport resources and destroy the dedicated transport devices before calling idr_destroy(). The destroy callback removed each entry from the same IDR being walked. That is not needed for this cleanup path, and it is unsafe because idr_for_each() has not advanced its radix-tree iterator while the callback is running. Removing the current entry from the callback can invalidate the iterator state. The callback also cannot be protected by rcu_read_lock(), because scmi_device_destroy() may sleep. Leave IDR teardown to the following idr_destroy() call and keep the callback limited to device destruction.

Affected packages

Ecosystem Package Introduced Fixed