CVE-2026-90397: firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published
In the Linux kernel, the following vulnerability has been resolved:
firmware: qcom: scm: Fix NULL dereference in IRQ handler before scm is published
In qcomscmprobe(), devmrequestthreadedirq() is called before smpstorerelease(&scm, scm). Two paths can dereference scm before it is published, both causing a NULL pointer dereference.
The IRQ handler receives scm via its data argument but passes only wqctx to qcomscmwaitqwakeup() and qcomscmgetcompletion(), which then dereference scm directly. Thread scm through both functions so the IRQ handler path never touches scm.
Non-atomic SMC calls made during probe (e.g. from qcomtzmeminit via qcomscmshmbridgeenable) can return WAITQSLEEP, causing qcomscmwaitforwqcompletion() to run before scm is published and dereference it. Add platformsetdrvdata(pdev, scm) early in probe and change qcomscmwaitforwqcompletion() to take the device pointer and use devgetdrvdata() to reach scm, removing any dependency on scm.
Event History
Frequently Asked Questions
When can the NULL pointer dereference occur?
It can occur during Qualcomm SCM driver probing before the global __scm pointer is published. The affected paths are an IRQ arriving after the threaded IRQ is registered and a non-atomic SMC call during probe that returns WAITQ_SLEEP.
What conditions are needed to trigger the issue?
An attacker is not described as needing network access, privileges, or a specific input. The failure depends on timing during driver initialization: either the IRQ handler must run early, or a probe-time non-atomic SMC operation must enter the wait-queue sleep path.
How can an affected system be identified from runtime behavior?
The described symptom is a NULL pointer dereference during qcom_scm_probe(), potentially involving the IRQ wakeup/completion path or qcom_scm_wait_for_wq_completion(). The provided data does not identify affected kernel versions or hardware models.
What does the fix change to prevent the crash?
The IRQ path is changed to use the SCM instance passed from the handler rather than dereferencing __scm. Probe-time wait-queue completion instead obtains the SCM instance through early platform driver data, so neither path relies on __scm before publication.