Cloudanix VulnDB

CVE-2026-90397

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Qualcomm driver initialization on Linux devices can crash the entire system during startup.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition during qcom_scm_probe allows IRQ handler and non-atomic SMC paths to dereference the global __scm pointer before smp_store_release publishes it, resulting in NULL pointer dereference.

Why it matters to the business

Kernel panic or system crash on Qualcomm-based Linux devices during driver initialization can cause boot failures, service disruption, and require manual intervention or reboot cycles.

How an attack unfolds

An attacker with local access triggers the probe sequence so that an IRQ or WAITQ_SLEEP path executes before __scm is initialized, causing the kernel to dereference NULL and panic.

How to fix it

Apply the upstream fix that threads the scm pointer through qcom_scm_waitq_wakeup, qcom_scm_get_completion, and qcom_scm_wait_for_wq_completion, and that calls platform_set_drvdata early in probe.

How to confirm the fix worked

Confirm the presence of the patched probe ordering and pointer-passing changes in the qcom_scm.c source; test boot on affected hardware without observing NULL dereference in the SCM IRQ path.

Typical attack path

  1. Gain local execution on a Qualcomm ARM device running a vulnerable kernel
  2. Trigger qcom_scm_probe via module load or device enumeration
  3. Time the IRQ or SMC completion path to run before __scm assignment
  4. Cause NULL dereference leading to kernel panic

How to detect it

Inspect kernel logs and dmesg for NULL pointer dereference oops originating from qcom_scm IRQ or wait-queue paths during early boot on Qualcomm hardware.

What your security team should do

  • Prioritize kernel updates containing the SCM probe ordering fix on all Qualcomm platforms
  • Monitor boot logs for SCM-related NULL pointer oops until patched kernels are deployed
  • Limit local access on unpatched systems to reduce trigger surface

The record

In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published In qcom_scm_probe(), devm_request_threaded_irq() is called before smp_store_release(&__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 wq_ctx to qcom_scm_waitq_wakeup() and qcom_scm_get_completion(), 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 qcom_tzmem_init via qcom_scm_shm_bridge_enable) can return WAITQ_SLEEP, causing qcom_scm_wait_for_wq_completion() to run before __scm is published and dereference it. Add platform_set_drvdata(pdev, scm) early in probe and change qcom_scm_wait_for_wq_completion() to take the device pointer and use dev_get_drvdata() to reach scm, removing any dependency on __scm.

Affected packages

Ecosystem Package Introduced Fixed