CVE-2026-93084: firmware: arm_scmi: Drop handle on protocol bind failures
In the Linux kernel, the following vulnerability has been resolved:
firmware: armscmi: Drop handle on protocol bind failures
The SCMI bus notifier acquires an SCMI handle when the driver core emits BUSNOTIFYBINDDRIVER, before invoking the protocol driver probe callback. The protocol probe path only checks whether sdev->handle is set.
If devicelinkadd() fails after the handle has been acquired, the protocol device can still bind with a valid handle but without the dependency link to the SCMI parent. A concurrent parent unbind can then miss the child and tear down the SCMI instance while the child still holds a handle into it.
If the protocol driver probe later fails, for example with -EPROBEDEFER, the driver core emits BUSNOTIFYDRIVERNOTBOUND rather than BUSNOTIFYUNBOUNDDRIVER. The SCMI notifier only released the handle on BUSNOTIFYUNBOUNDDRIVER, so each failed protocol-device bind leaked the SCMI instance users refcount and left sdev->handle set after the failed probe.
Make the link helper report failure and drop the acquired handle if the link cannot be created. Also handle BUSNOTIFYDRIVERNOTBOUND in the same cleanup path used for unbind so failed probes balance the earlier BUSNOTIFYBINDDRIVER acquisition.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using the Linux kernel SCMI bus with protocol devices and protocol drivers are relevant. The failure paths involve SCMI protocol-driver binding, SCMI parent-device unbinding, and device-link creation.
What conditions are needed for the use-after-teardown risk?
An SCMI handle must be acquired during driver binding, followed by failure to create the dependency link to the SCMI parent. If the protocol device subsequently binds without that link, a concurrent parent unbind can tear down the SCMI instance while the child retains its handle.
What happens when a protocol driver probe fails?
A failed probe, including a failure such as -EPROBE_DEFER, produces BUS_NOTIFY_DRIVER_NOT_BOUND rather than BUS_NOTIFY_UNBOUND_DRIVER. Before the fix, this path did not release the SCMI handle, so repeated failed protocol-device binds could leak SCMI instance user references and leave sdev->handle set.