CVE-2026-93086 in Linux
Summary
by MITRE • 09/17/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel vulnerability identified in the ARM SCMI subsystem involves a critical concurrency flaw within the firmware interface driver, specifically during the cleanup phase of transport channels. The System Control and Management Interface (SCMI) is an industry-standard protocol that allows software running on processors to manage hardware components such as power domains, clocks, and performance scaling mechanisms. In this specific instance, the function scmi_cleanup_channels() was designed to iterate through transaction ID allocation descriptors using idr_for_each() to free transport resources and destroy dedicated transport devices before ultimately calling idr_destroy(). The core technical flaw lies in the interaction between the iteration mechanism and the callback function used during cleanup.
The root cause of this vulnerability is that the destroy callback invoked for each entry was removing entries from the same IDR being actively walked by idr_for_each(). This operation is unsafe because the radix-tree iterator maintained by idr_for_each() does not advance its state while a callback is executing. When an entry is removed from within the callback, it invalidates the internal pointer or index used to traverse the tree structure. Consequently, this can lead to memory corruption, kernel panics, or undefined behavior as the iteration logic attempts to access nodes that have been detached or modified mid-traversal. This type of error represents a classic race condition where concurrent modification of data structures during traversal leads to structural integrity failure within the kernel's internal management systems.
From a classification perspective, this vulnerability aligns with CWE-362, which describes Concurrent Execution using Shared Resource with Improper Synchronization, specifically involving resource access without proper locking or synchronization mechanisms that account for iterator stability. Furthermore, it relates to CWE-824, Access of Uninitialized Pointer, as the invalidation of the iterator can lead to dereferencing memory addresses that are no longer valid or point to freed resources. The vulnerability is exploitable in scenarios where channel cleanup occurs under concurrent load conditions, potentially allowing a local attacker with sufficient privileges to trigger a denial-of-service condition by causing kernel instability through repeated allocation and deallocation cycles that stress the IDR management logic.
The operational impact of this flaw includes potential system crashes or freezes when SCMI channels are dynamically removed or reset. Since firmware interfaces often interact closely with hardware state, such instabilities can lead to broader system reliability issues, particularly in embedded systems or servers where power management and performance scaling rely heavily on stable communication between the operating system and firmware agents. The inability to safely clean up resources without corrupting internal kernel data structures means that any process triggering this cleanup path risks destabilizing the entire kernel environment.
The resolution involves restructuring the callback logic within scmi_cleanup_channels() to separate resource destruction from IDR management. By limiting the callback strictly to device destruction tasks and leaving the actual teardown of ID entries to the subsequent idr_destroy() call, the iterator remains stable throughout the traversal process. This approach ensures that the radix-tree structure is not modified while it is being walked, thereby preserving the integrity of the iteration state. Additionally, since scmi_device_destroy() may sleep, protecting the operation with rcu_read_lock was deemed inappropriate and potentially deadlock-prone; thus, deferring IDR removal to a non-sleeping context or after traversal completion provides a safer synchronization model without introducing new locking complexities.
To mitigate similar issues in kernel development, it is essential to adhere strictly to best practices regarding data structure iteration. Developers must ensure that callbacks invoked during tree traversals do not modify the structural elements being iterated over unless explicitly supported by the API semantics. In this case, leveraging idr_destroy() for bulk removal after traversal completes eliminates the risk of iterator invalidation. Security auditors and kernel maintainers should review similar patterns in other subsystems where IDR or radix-tree iterations are coupled with dynamic entry removal to prevent recurrence of such concurrency-related memory corruption vulnerabilities.