CVE-2024-57985 in Linux
Summary
by MITRE • 02/27/2025
In the Linux kernel, the following vulnerability has been resolved:
firmware: qcom: scm: Cleanup global '__scm' on probe failures
If SCM driver fails the probe, it should not leave global '__scm' variable assigned, because external users of this driver will assume the probe finished successfully. For example TZMEM parts ('__scm->mempool') are initialized later in the probe, but users of it (__scm_smc_call()) rely on the '__scm' variable.
This fixes theoretical NULL pointer exception, triggered via introducing probe deferral in SCM driver with call trace:
qcom_tzmem_alloc+0x70/0x1ac (P) qcom_tzmem_alloc+0x64/0x1ac (L) qcom_scm_assign_mem+0x78/0x194 qcom_rmtfs_mem_probe+0x2d4/0x38c platform_probe+0x68/0xc8
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 05/24/2026
The vulnerability described in CVE-2024-57985 resides within the Linux kernel's Qualcomm Secure Core Manager (SCM) driver implementation, specifically concerning the improper handling of global state variables during driver probe failures. This issue manifests when the SCM driver encounters an error during its initialization phase, leaving the global '__scm' variable in an inconsistent state where it appears to be initialized but actually contains invalid or null references. The problem stems from the driver's failure to properly clean up the global state when probe operations do not complete successfully, creating a dangerous condition where external components that depend on this driver's initialization assume proper functionality has occurred.
The technical flaw represents a classic improper error handling pattern where the driver does not adequately reset or clean global variables upon probe failure conditions. When the SCM driver fails to initialize properly, it leaves the '__scm' global variable assigned to a partially initialized state, which subsequent code paths then attempt to use without proper validation. This creates a scenario where external users of the driver, particularly components like TZMEM parts that rely on '__scm->mempool' initialization, operate under false assumptions about the driver's operational status. The vulnerability specifically impacts the qcom_tzmem_alloc function and related memory management operations that depend on the SCM driver's proper initialization sequence.
The operational impact of this vulnerability extends beyond simple theoretical null pointer exceptions to potentially disrupt system stability and security functionality. When probe deferral is introduced into the SCM driver, the call trace demonstrates how the failure propagates through the system, with qcom_tzmem_alloc calling qcom_scm_assign_mem which then attempts to access the improperly initialized global variable. This creates a cascading failure where memory management operations that should be protected by proper driver initialization instead become vulnerable to accessing null references. The vulnerability affects systems using Qualcomm SoCs that rely on the SCM driver for secure memory management and trusted execution environment operations.
The fix implemented addresses this issue by ensuring proper cleanup of the global '__scm' variable whenever the SCM driver probe fails to complete successfully. This remediation follows established security practices for error handling in kernel modules, where global state must be properly managed to prevent inconsistent states that could be exploited by malicious actors. The solution aligns with CWE-252, which addresses improper checks for error conditions, and addresses potential ATT&CK techniques related to privilege escalation and system stability compromise. System administrators should ensure their kernel versions include this patch to prevent potential exploitation that could lead to denial of service conditions or unauthorized access to secure memory regions managed by the SCM driver. The vulnerability highlights the importance of proper state management in kernel drivers and demonstrates how seemingly minor error handling oversights can create significant security implications in embedded systems.