CVE-2025-39941 in Linux
Summary
by MITRE • 10/04/2025
In the Linux kernel, the following vulnerability has been resolved:
zram: fix slot write race condition
Parallel concurrent writes to the same zram index result in leaked zsmalloc handles. Schematically we can have something like this:
CPU0 CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() zram_slot_lock() zs_free(handle) zram_slot_lock()
compress compress handle = zs_malloc() handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle(handle) zram_slot_lock
Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done too early. In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 04/28/2026
The vulnerability identified as CVE-2025-39941 represents a critical race condition within the Linux kernel's zram subsystem that specifically affects the zsmalloc memory allocator implementation. This issue manifests when multiple concurrent threads attempt to write to the same zram index simultaneously, creating a scenario where memory management operations become inconsistent and lead to resource leakage. The zram subsystem serves as a compressed swap space implementation that allows the kernel to use RAM as virtual swap space, with zsmalloc providing the underlying memory allocation mechanism for these compressed storage entries.
The technical flaw occurs due to improper synchronization around the zram slot locking mechanism during concurrent write operations. When two or more CPUs attempt to write to the same zram index simultaneously, the locking sequence becomes problematic. The race condition arises because the zsmalloc handle is freed prematurely before the new handle is properly set, creating a window where one of the allocated handles becomes unreachable and leaked from the system's memory management pool. This improper ordering of operations violates fundamental principles of concurrent programming and memory safety, where critical sections must maintain atomicity and consistency.
The operational impact of this vulnerability extends beyond simple memory leakage, potentially leading to system instability and resource exhaustion over time. When zsmalloc handles leak due to the race condition, the available memory pool for zram operations gradually diminishes, which can result in reduced system performance, increased swap pressure, and ultimately system crashes or hangs. The vulnerability affects systems heavily utilizing zram as swap space, particularly those running virtualization workloads or memory-constrained environments where compressed swap operations are frequently performed. This makes the issue particularly concerning for cloud computing platforms, containerized environments, and embedded systems that rely heavily on zram functionality.
The root cause of this vulnerability aligns with CWE-362, which describes a race condition in concurrent programming where multiple threads access shared resources without proper synchronization, leading to unpredictable behavior and resource leaks. The flaw also relates to CWE-691, which addresses insufficient control of generation of code, as the improper locking sequence can lead to memory corruption and invalid state transitions. From an ATT&CK framework perspective, this vulnerability could be leveraged for resource exhaustion attacks or potentially used as a stepping stone for more sophisticated exploits targeting memory management subsystems. The proper mitigation requires ensuring that all zram entry modifications occur under a single, unified lock scope that encompasses both the freeing of old handles and the allocation of new ones, preventing any interleaving of operations that could lead to handle leakage. This fix ensures that the zram subsystem maintains atomicity in its memory management operations and prevents the scenario where one thread's operations interfere with another's, thereby preserving system integrity and preventing the accumulation of leaked memory resources.