CVE-2026-90397: firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published
firmware: qcom: scm: Fix NULL dereference in IRQ handler before scm is published
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.1.176-1Fixed in 6.1.190-1Fixed 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
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.