CVE-2026-93091: firmware: arm_scmi: Quiesce notifications before teardown
In the Linux kernel, the following vulnerability has been resolved:
firmware: armscmi: Quiesce notifications before teardown
scminotificationexit() clears and releases the notification instance, but transport callbacks can still deliver incoming notifications until the TX/RX channels are freed. During remove, an RX interrupt in that window can enter scminotify() while notification state is being torn down and then dereference freed memory. The same ordering exists on the probe error path after notification initialization.
The notification late-init worker has a separate lifetime issue: protocol event registration queues ni->initwork on the system workqueue, so destroying ni->notifywq does not drain that work. If the devres group is released while initwork is still pending or running, the late-init worker can dereference the freed notification instance.
Quiesce the notification core before TX/RX channels are torn down, then clean up the channels before releasing the notification core resources. Use disableworksync() so future late-init queueing is rejected and any already queued or running late-init work has completed before channel teardown starts.
Affected Software
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.