CVE-2026-93081 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix SCMI device destroy lifetimes
scmi_child_dev_find() drops the reference returned by device_find_child() before returning the scmi_device pointer. A concurrent unregister can then release the device while the destroy path is still using the returned pointer.
Make the lookup helper return the device_find_child() reference and keep it until scmi_device_destroy() has finished unregistering the child.
Also split device_unregister() in __scmi_device_destroy() so the SCMI bus ID is not made reusable until after device_del() has removed the old scmi_dev.N name from sysfs. This avoids a new SCMI device reusing the same ID while the old device is still registered.
The final device release callback is also a possible cleanup path when SCMI children are deleted by driver core recursion rather than __scmi_device_destroy(). Release the SCMI bus ID from a common helper used by destroy, register-failure and final-release paths, and clear scmi_dev->id after freeing it so the final release cannot free the same ID again.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel vulnerability identified in the ARM System Control and Management Interface (SCMI) subsystem involves a critical use-after-free condition arising from improper reference counting during device lifecycle management. The core technical flaw resides within the scmi_child_dev_find helper function, which retrieves a pointer to an SCMI child device using device_find_child but subsequently drops the associated reference count before returning the scmi_device structure to its caller. This premature release of the reference creates a race condition window where concurrent operations can lead to data corruption or kernel instability. Specifically, if a device unregister operation occurs while the destroy path is still utilizing the returned pointer, the underlying memory may be freed and reallocated for other purposes before the original user completes its access, resulting in a classic use-after-free vulnerability that compromises system integrity and stability.
The operational impact of this flaw extends beyond simple memory corruption to include potential denial of service scenarios where kernel panics or unexpected reboots can occur due to invalid memory accesses. Furthermore, the issue encompasses resource management errors related to device identifiers on the SCMI bus. The original implementation did not adequately synchronize the release of device resources with their removal from system interfaces such as sysfs. This lack of synchronization allowed for a scenario where an old SCMI device identifier could be reused by a new device before the previous instance was fully unregistered, leading to conflicts in device identification and potential misrouting of control messages within the firmware interface layer.
To remediate this vulnerability, the kernel developers implemented several structural changes to enforce strict lifecycle management protocols. The lookup helper function scmi_child_dev_find was modified to retain the reference obtained from device_find_child until the scmi_device_destroy routine has completely finished unregistering the child device. This ensures that the memory associated with the SCMI device remains valid throughout its entire destruction sequence, eliminating the race condition window. Additionally, the logic for device unregistration was refactored by splitting the device_unregister call into a dedicated __scmi_device_destroy function. This separation guarantees that the SCMI bus identifier is not marked as reusable until after device_del has successfully removed the old scmi_dev.N name from sysfs, thereby preventing ID reuse conflicts and ensuring clean state transitions during device removal.
The final phase of the remediation addresses edge cases involving driver core recursion where children are deleted automatically rather than through explicit destroy calls. A common helper function was introduced to manage the release of SCMI bus identifiers across all relevant paths, including destruction routines, registration failure handlers, and final release callbacks. This centralized approach ensures consistent resource cleanup regardless of how the device lifecycle ends. Crucially, the implementation includes a safeguard where scmi_dev->id is cleared immediately after being freed. This prevents double-free vulnerabilities by ensuring that subsequent attempts to free the same identifier are safely ignored due to the nullified state, thereby closing any remaining gaps in memory safety and resource management within the SCMI subsystem.
From a classification perspective, this vulnerability aligns with CWE-416 Use After Free, which describes situations where software continues to use a pointer after it has been freed, leading to unpredictable behavior or security breaches. The race condition aspect also relates to CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, as the bug stems from insufficient locking or reference counting during concurrent device operations. In terms of attack vectors and defensive mapping, this issue falls under MITRE ATT&CK technique T1059 Command Scripting if an attacker could exploit the instability to execute arbitrary code via kernel panic triggers, though primarily it represents a stability risk rather than a direct privilege escalation path in most standard configurations. Mitigation strategies involve applying the specific kernel patches that enforce proper reference counting and synchronize device unregistration with sysfs removal processes. System administrators should ensure their Linux kernels are updated to versions containing these fixes to maintain the integrity of ARM SCMI-based firmware interfaces and prevent potential denial-of-service conditions arising from concurrent device management operations.