CVE-2026-90397 in Linux
Summary
by MITRE • 09/17/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel driver for Qualcomm Secure Channel Manager contains a critical race condition vulnerability that results in a NULL pointer dereference during system initialization. This flaw arises from an improper ordering of operations within the qcom_scm_probe function, where the device management request for a threaded interrupt is established before the global __scm structure pointer is published to other parts of the kernel using smp_store_release. Because the interrupt handler and subsequent completion wait mechanisms rely on accessing this global variable, any execution path that triggers an interrupt or waits for work queue completion prior to the publication step will attempt to dereference a NULL pointer. This specific timing issue highlights a fundamental synchronization error where shared state is accessed before it has been safely made visible to concurrent execution contexts.
The technical root cause involves two distinct code paths within the driver logic. The first path occurs when the IRQ handler executes, passing only the work queue context to helper functions like qcom_scm_waitq_wakeup and qcom_scm_get_completion. These internal functions directly reference the global __scm variable rather than using a locally passed or device-specific pointer. Since the interrupt may fire immediately upon registration but before smp_store_release completes, these dereferences fail. The second path involves non-atomic SMC calls made during the probe phase itself, such as those initiated by qcom_tzmem_init via qcom_scm_shm_bridge_enable. If such a call returns WAITQ_SLEEP, it triggers qcom_scm_wait_for_wq_completion to run before __scm is published, leading again to a NULL dereference due to the same dependency on the uninitialized global variable.
From an operational perspective, this vulnerability can cause immediate kernel panics or system crashes during boot sequences that involve Qualcomm hardware initialization. The impact is particularly severe because it occurs early in the driver lifecycle, potentially preventing the operating system from fully initializing critical subsystems dependent on secure channel communications. An attacker with physical access to a device could trigger these conditions by manipulating power states or triggering specific hardware events rapidly after reset, although exploitation typically results only in denial of service rather than arbitrary code execution due to the nature of NULL pointer dereferences in kernel space. The lack of proper synchronization primitives ensures that any concurrent access during this narrow window leads to instability and potential system unavailability.
To mitigate this vulnerability, developers must ensure strict ordering between resource allocation and state publication. The recommended fix involves threading the scm structure through all relevant functions so that the IRQ handler path never directly accesses the global __scm variable. Specifically, platform_set_drvdata should be called early in the probe function to associate the device pointer with the driver data. Subsequently, qcom_scm_wait_for_wq_completion must be modified to accept a device pointer and utilize dev_get_drvdata() to retrieve the scm structure locally. This approach removes any dependency on the global __scm variable during initialization, ensuring that all accesses are safe regardless of timing variations or interrupt latency.
This vulnerability aligns with CWE-476, which describes NULL Pointer Dereference vulnerabilities resulting from improper checks for null values before use. In terms of attack patterns and detection methodologies, this scenario reflects aspects of ATT&CK technique T1059, specifically command scripting or system utility abuse if the crash leads to a fallback into recovery modes that could be manipulated. Furthermore, it illustrates CWE-362 regarding concurrent execution issues where race conditions arise from insufficient synchronization between threads accessing shared resources. Proper implementation of memory barriers and device data management is essential to prevent such races in kernel drivers handling hardware interrupts and secure communication channels.