Cloudanix VulnDB

CVE-2026-93080

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug on certain ARM hardware could let badly formed setup data from firmware cause crashes or errors during normal device handling.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw stems from shared protocol/name lookup logic that deliberately excludes SCMI transport devices from bus matching; scmi_device_destroy() therefore cannot locate them for unregistration, and duplicate protocol channel setup is not rejected, allowing malformed firmware to reuse an existing transport device and trigger its destruction on subsequent IDR insertion failure.

Why it matters to the business

ARM-based Linux systems using SCMI may experience device management failures or instability when presented with malformed firmware, increasing operational risk for servers and embedded platforms until the kernel is updated.

How an attack unfolds

An attacker or compromised firmware supplies duplicate SCMI protocol child nodes; during channel setup the kernel reuses an existing transport device, duplicate IDR insertion fails, and the erroneous teardown path destroys the device, leading to resource mismanagement or kernel instability.

How to fix it

Apply the upstream kernel patch that splits the match helper, introduces a shared transport-device name prefix macro, and rejects duplicate protocol channel setup before transport device creation or lookup.

How to confirm the fix worked

Inspect kernel source or running system for separate driver-matching versus teardown lookup functions, presence of the transport-device name prefix macro, and explicit duplicate-protocol rejection before IDR insertion.

Typical attack path

  1. Deliver malformed firmware containing duplicate SCMI protocol nodes
  2. Trigger SCMI channel setup and transport device creation
  3. Force duplicate protocol IDR insertion that fails
  4. Invoke scmi_device_destroy with incorrect lookup resulting in improper device teardown

How to detect it

Review kernel logs for SCMI transport device creation, duplicate protocol warnings, or teardown failures; examine dmesg and device-tree for unexpected duplicate protocol child nodes during boot or runtime channel initialization.

What your security team should do

  • Prioritize kernel updates containing the SCMI transport teardown fix on all affected ARM systems
  • Harden firmware sources and validate SCMI device-tree contents for duplicate protocol nodes
  • Monitor kernel logs for SCMI channel setup and teardown anomalies until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix transport device teardown lookup SCMI transport devices are deliberately excluded from normal SCMI bus matching so protocol drivers cannot bind to the internal transport children. However, scmi_device_destroy() uses the same protocol/name lookup to find devices that must be unregistered during channel teardown. Split the match helper so driver matching still skips transport devices, while explicit child lookup can find them for teardown. Use a shared transport-device name prefix macro for both matching and name generation. Since transport-device names are derived from direction and protocol ID, reject duplicate protocol channel setup before creating or finding a transport device. This prevents malformed firmware with duplicate protocol child nodes from reusing an existing transport device and then destroying it when the duplicate IDR insertion fails.

Affected packages

Ecosystem Package Introduced Fixed