Cloudanix VulnDB

CVE-2026-93081

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing bug in the Linux kernel's handling of certain hardware management devices on ARM chips can let the system crash or become unstable when multiple operations overlap.

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

Race condition in scmi_child_dev_find() drops the device reference from device_find_child() before return, allowing concurrent unregister to free the SCMI device while the destroy path still holds a dangling pointer; also mishandles bus ID reuse and final-release cleanup paths.

Why it matters to the business

Kernel instability or crashes on ARM systems that rely on SCMI firmware interfaces for power, clock, and sensor management, potentially causing downtime in servers, embedded devices, and virtualization hosts.

How an attack unfolds

An attacker triggers concurrent SCMI child device registration and unregistration operations; the premature reference drop creates a window for use-after-free when the destroy path dereferences the now-freed device, which can be leveraged for memory corruption or denial of service.

How to fix it

Apply the upstream fix that keeps the device_find_child() reference until __scmi_device_destroy() completes, splits device_unregister(), and centralizes SCMI bus ID release in a common helper; rebuild and deploy the patched kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting the arm_scmi driver source for the updated scmi_child_dev_find() and __scmi_device_destroy() logic, or verify the running kernel contains the commit that resolves the lifetime issue.

Typical attack path

  1. Gain local access or trigger SCMI device lifecycle events via userspace or driver interactions
  2. Race scmi_device registration against unregister paths
  3. Trigger use-after-free through the dangling pointer in the destroy helper
  4. Escalate the resulting memory corruption to kernel code execution or crash

How to detect it

Inspect kernel logs for oops, use-after-free warnings, or panics mentioning scmi_device, scmi_child_dev_find, or __scmi_device_destroy; correlate with SCMI bus device registration/unregistration events.

What your security team should do

  • Expedite kernel updates on all ARM platforms that load the scmi driver
  • Review systems for heavy SCMI device churn workloads that increase race exposure
  • Add kernel oops and scmi-related panic alerts to monitoring

The record

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.

Affected packages

Ecosystem Package Introduced Fixed