CVE-2026-64031 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix managed cache race for unaligned extents
After unaligned compressed extents were introduced, the following race could occur:
[Thread 1] [Thread 2]
(z_erofs_fill_bio_vec) <handle a Z_EROFS_PREALLOCATED_FOLIO folio> ... filemap_add_folio (1) (z_erofs_bind_cache) <the same folio is found..> .. .. folio_attach_private (2) filemap_add_folio (3) again
Since (1) is executed but (2) hasn't been executed yet, it's possible that another thread finds the same managed folio in z_erofs_bind_cache() for a different pcluster and calls filemap_add_folio() again since folio->private is still Z_EROFS_PREALLOCATED_FOLIO.
Fix this by explicitly clearing folio->private before making the folio visible in the managed cache so that another pcluster can simply wait on the locked managed folio as what we did for other shared cases [1].
This only impacts unaligned data compression (`-E48bit` with zstd, for example).
[1] Commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of
crafted images properly") was originally introduced to handle crafted overlapped extents, but it addresses unaligned extents as well.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability exists within the Linux kernel's erofs filesystem implementation where a race condition can occur during managed cache operations involving unaligned compressed extents. This flaw specifically manifests when the kernel processes zstd compression with the -E48bit flag, creating a scenario where multiple threads can concurrently access the same folio structure while it transitions through different states in the caching mechanism.
The race condition occurs between two distinct thread operations that manipulate the same memory structure. Thread 1 executes z_erofs_fill_bio_vec and begins handling a Z_EROFS_PREALLOCATED_FOLIO folio, calling filemap_add_folio at step (1). Meanwhile, Thread 2 executes z_erofs_bind_cache and discovers the same folio, attempting to bind it to a different pcluster. The critical timing issue arises because step (1) completes execution before step (2) - folio_attach_private - is finished, leaving the folio in a transitional state where folio->private still contains Z_EROFS_PREALLOCATED_FOLIO.
This race condition creates a dangerous scenario where multiple threads can independently process the same folio structure, potentially leading to inconsistent cache states and data corruption. The vulnerability stems from insufficient synchronization between the folio preparation phase and its visibility within the managed cache system, violating fundamental principles of concurrent programming and memory safety protocols that are essential for filesystem stability.
The fix implements a defensive programming approach by explicitly clearing folio->private before making the folio visible in the managed cache, ensuring that subsequent accesses by different threads will properly synchronize on the locked managed folio. This solution aligns with established patterns used for other shared cases within the same codebase and addresses the specific issue introduced by commit 9e2f9d34dd12 which was originally designed to handle crafted overlapped extents but inadvertently also affects unaligned compression scenarios.
This vulnerability has implications for filesystem integrity and could potentially enable privilege escalation or data corruption attacks, particularly in environments where concurrent access patterns are common. The issue specifically impacts systems utilizing zstd compression with the -E48bit flag, making it relevant to modern Linux distributions that support advanced compression algorithms within their erofs implementations. The fix addresses a CWE-362 race condition vulnerability and aligns with ATT&CK tactics related to privilege escalation and credential access through kernel-level vulnerabilities.
The technical flaw represents a failure in proper memory synchronization between concurrent threads accessing shared data structures, where the premature visibility of a folio structure creates opportunities for inconsistent state management. This type of vulnerability is particularly concerning in kernel space where improper synchronization can lead to system instability, data corruption, or security exploits that may compromise the integrity of the entire filesystem layer.
Security implications extend beyond simple data consistency issues as this race condition could potentially be exploited by malicious actors to manipulate cached data or gain unauthorized access to filesystem resources. The vulnerability's specificity to unaligned compressed extents means that it affects only certain compression configurations, but those configurations remain common in modern filesystem implementations where performance optimization through advanced compression is prioritized over absolute security isolation.
The mitigation strategy follows established kernel development practices for handling shared resource contention and demonstrates the importance of careful synchronization in high-concurrency scenarios. This fix reinforces proper memory ordering principles and ensures that folio structures transition through their lifecycle states atomically, preventing the conditions that enabled the original race condition to occur within the erofs managed cache subsystem.