CVE-2025-21998 in Linux
Summary
by MITRE • 04/03/2025
In the Linux kernel, the following vulnerability has been resolved:
firmware: qcom: uefisecapp: fix efivars registration race
Since the conversion to using the TZ allocator, the efivars service is registered before the memory pool has been allocated, something which can lead to a NULL-pointer dereference in case of a racing EFI variable access.
Make sure that all resources have been set up before registering the efivars.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 02/16/2026
The vulnerability identified as CVE-2025-21998 represents a critical race condition within the Qualcomm firmware subsystem of the Linux kernel, specifically affecting the uefisecapp driver component. This issue manifests during the initialization sequence of the EFI variables service, where the timing of resource allocation and service registration creates a window for potential system instability. The flaw occurs when the kernel transitions to using the Trusted Zone (TZ) allocator for memory management, which alters the expected initialization order of system components. The vulnerability is particularly concerning because it directly impacts the foundational firmware interfaces that enable secure boot processes and firmware configuration management.
The technical root cause of this vulnerability lies in the improper sequencing of initialization operations within the kernel's firmware subsystem. Specifically, the efivars service registration occurs before the memory pool allocation process completes, creating a scenario where concurrent access to EFI variables can trigger a NULL-pointer dereference. This race condition represents a classic synchronization issue where the system attempts to use resources that have not yet been properly initialized. The vulnerability is classified under CWE-362, which specifically addresses Race Conditions, and more precisely aligns with CWE-367, which deals with Time-of-Check to Time-of-Use (TOCTOU) errors. The flaw demonstrates poor resource management practices where the kernel fails to ensure proper initialization ordering before exposing system interfaces to concurrent access patterns.
The operational impact of this vulnerability extends beyond simple system crashes, potentially enabling attackers to exploit the race condition for privilege escalation or system compromise. When EFI variables are accessed during the brief window between service registration and memory pool allocation, the system may experience unpredictable behavior including kernel panics, memory corruption, or denial of service conditions. This vulnerability particularly affects systems utilizing Qualcomm-based hardware platforms that rely on the uefisecapp driver for secure firmware operations. The attack surface is significant because EFI variables are critical for maintaining system integrity and secure boot processes, making this vulnerability potentially exploitable for bypassing security measures or establishing persistent access to affected systems. The timing aspect of this race condition means that exploitation could occur during normal system operations when EFI variables are being accessed for legitimate purposes.
Mitigation strategies for CVE-2025-21998 require immediate kernel updates from vendors who have addressed this specific race condition in their firmware implementations. System administrators should prioritize patching affected systems to ensure proper resource initialization sequencing before exposing EFI variable services to concurrent access. The fix implemented by kernel developers addresses the core issue by ensuring that all necessary resources are fully allocated and initialized before the efivars service registration occurs. Organizations should also implement monitoring for unusual system behavior or kernel panic events that might indicate exploitation attempts. From an ATT&CK perspective, this vulnerability maps to techniques involving privilege escalation and system modification, as it could potentially be leveraged to compromise the secure boot process. The fix demonstrates proper defensive programming practices that align with secure coding guidelines, ensuring proper initialization ordering and resource management to prevent similar race conditions in firmware subsystems.