CVE-2026-93091: firmware: arm_scmi: Quiesce notifications before teardown
firmware: armscmi: Quiesce notifications before teardown
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
Quiesce the SCMI notification core before tearing down TX/RX channels; use disable_work_sync() to reject future late-init queueing and wait for queued or running init_work to complete, then clean up the channels before releasing notification-core resources. Apply the same ordering on the probe error path after notification initialization.
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel ARM SCMI firmware driver with notification handling are exposed during driver removal or probe-error cleanup. The vulnerable paths involve active SCMI transport TX/RX channels and notification initialization or delivery.
What conditions are required to trigger the use-after-free?
An incoming RX notification must be delivered while notification state is being torn down, or the late-init worker must remain queued or run after the notification instance is released. These conditions can occur during driver removal and on the probe error path after notification initialization.
What is the mitigation if an updated kernel cannot be deployed immediately?
The provided data does not identify a configuration workaround. Reducing or avoiding SCMI driver removal, teardown, and failed probe scenarios may reduce exposure, but the resolution described is to quiesce notifications and synchronize late-init work before channel teardown.