CVE-2026-93080: firmware: arm_scmi: Fix transport device teardown lookup

Published Sep 17, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved:

firmware: armscmi: 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, scmidevicedestroy() 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.

Event History

Sep 17, 2026

CVE Published

via MITRE·04:11 PM

Data Sourced

via MITRE·04:11 PM

Description

Frequently Asked Questions

What systems are realistically exposed to this issue?

Systems using the Linux kernel SCMI firmware interface with transport devices are relevant. The failure scenario specifically involves malformed firmware that exposes duplicate protocol child nodes.

What condition triggers the unsafe teardown behavior?

A duplicate protocol channel setup can derive the same transport-device name as an existing channel. If the duplicate IDR insertion then fails, the existing transport device can be reused and subsequently destroyed during cleanup.

Is normal SCMI protocol driver binding to transport devices part of the issue?

No. Transport devices are intentionally excluded from normal SCMI bus matching so protocol drivers cannot bind to them. The fix separates that driver-matching behavior from explicit child lookup needed during teardown.

What should be checked when determining whether a system may be affected?

Review SCMI firmware channel and protocol child-node definitions for duplicate protocol IDs, particularly where channel direction and protocol ID would generate the same transport-device name. Also verify whether the kernel includes the referenced stable fixes.

CVE-2026-93080: firmware: arm_scmi: Fix transport device teardown lookup

Event History

Frequently Asked Questions

What systems are realistically exposed to this issue?

What condition triggers the unsafe teardown behavior?

Is normal SCMI protocol driver binding to transport devices part of the issue?

What should be checked when determining whether a system may be affected?

Company

Resources

Contact

Frequently Asked Questions

What systems are realistically exposed to this issue?

What condition triggers the unsafe teardown behavior?

Is normal SCMI protocol driver binding to transport devices part of the issue?

What should be checked when determining whether a system may be affected?