CVE-2026-93093: firmware: arm_scmi: Publish channel state before callbacks
In the Linux kernel, the following vulnerability has been resolved:
firmware: armscmi: Publish channel state before callbacks
Transport setup can enable callbacks before the setup routine returns. mailboxchansetup() registers the mailbox client with mboxrequestchannel(), and the mailbox controller startup path can enable interrupt delivery before SCMI mailbox channel state has been published. Similarly, smcchansetup() requests the optional A2P completion IRQ before the SMC transport has made its cinfo pointer visible.
If a pending or spurious callback fires in those windows, the transport RX callback can dereference a NULL transport cinfo pointer. Publishing only the transport-private pointer is not sufficient either: an early callback can enter the SCMI core before scmichansetup() has assigned cinfo->handle. The core derives scmiinfo from cinfo->handle in the RX path, so a NULL handle can still fault even when the transport-private cinfo is valid.
Assign cinfo->handle before invoking the transport setup callback. Publish the mailbox and SMC transport-private channel state before requesting the mailbox channels or IRQ, and clear the early-published pointers again on setup failure. Also unwind mailbox setup devres resources on failure so an optional RX setup error that is ignored by the core does not leave stale transport state behind.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the kernel fix: publish SCMI/arm_scmi mailbox channel state (and handle pointers) before transport setup callbacks/optional A2P completion IRQs can run, assign cinfo->handle before invoking the transport setup callback, and clear early-published pointers again on setup failure so any spurious/pending callback cannot dereference NULL or stale transport-private cinfo.
Linux kernel firmware: arm_scmi (SMC transport / mailbox channels) Publish channel/mailbox state before enabling callbacks and interrupts; assign cinfo->handle before invoking transport setup callback; clear early-published pointers on failure = Implement ordering fixes described in the resolved advisory: assign cinfo->handle before invoking transport setup callback; publish mailbox channel state before optional RX setup/IRQ delivery and before registering callbacks; on mailbox_chan_setup() failure, clear early-published pointers to avoid stale state; ensure early/pending/spurious callbacks do not dereference a NULL transport cinfo pointer
Event History
Frequently Asked Questions
Which transport configurations are implicated?
The affected setup paths are the SCMI mailbox transport and the SMC transport when its optional A2P completion IRQ is requested. The issue occurs during channel setup, before the transport and SCMI core state are fully published.
What must occur for the fault to be triggered?
A pending or spurious mailbox callback, or an early completion IRQ callback, must fire during the setup window. The receive path can then dereference a NULL transport cinfo pointer or a NULL cinfo->handle-derived SCMI core pointer.
Is initializing only the transport-private channel pointer sufficient to prevent the crash?
No. An early callback can reach the SCMI core before cinfo->handle is assigned, and the core receive path derives scmi_info from that handle; it can still fault even if the transport-private cinfo pointer is valid.