In the Linux kernel, the following vulnerability has been resolved: erofs: fix managed cache race for unaligned extents After unaligned compressed… (CVE-2026-64031)
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.
AI Analysis
Technical Summary
CVE-2026-64031 addresses a race condition in the Linux kernel's erofs filesystem related to unaligned compressed extents. When handling a Z_EROFS_PREALLOCATED_FOLIO folio, one thread may execute filemap_add_folio before another thread completes folio_attach_private, causing the same folio to be added multiple times concurrently. This occurs because folio->private remains set to Z_EROFS_PREALLOCATED_FOLIO, allowing multiple threads to act on the same folio for different pclusters. The patch clears folio->private before making the folio visible in the managed cache, ensuring that other threads wait on the locked folio instead of duplicating operations. This vulnerability specifically impacts unaligned data compression modes such as -E48bit with zstd.
Potential Impact
The vulnerability can lead to race conditions in the erofs filesystem when handling unaligned compressed extents, potentially causing data corruption or inconsistent filesystem state due to concurrent manipulation of the same managed folio. The impact is limited to scenarios using unaligned data compression in erofs and does not affect other compression modes or filesystems.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to clear the folio->private field before exposing the folio in the managed cache, preventing concurrent threads from adding the same folio multiple times. Users should update to a Linux kernel version that includes this fix. Patch status is not explicitly confirmed in the provided data; therefore, check the vendor or Linux kernel advisories for the specific fixed version and apply the update accordingly.
In the Linux kernel, the following vulnerability has been resolved: erofs: fix managed cache race for unaligned extents After unaligned compressed… (CVE-2026-64031)
Description
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.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
CVE-2026-64031 addresses a race condition in the Linux kernel's erofs filesystem related to unaligned compressed extents. When handling a Z_EROFS_PREALLOCATED_FOLIO folio, one thread may execute filemap_add_folio before another thread completes folio_attach_private, causing the same folio to be added multiple times concurrently. This occurs because folio->private remains set to Z_EROFS_PREALLOCATED_FOLIO, allowing multiple threads to act on the same folio for different pclusters. The patch clears folio->private before making the folio visible in the managed cache, ensuring that other threads wait on the locked folio instead of duplicating operations. This vulnerability specifically impacts unaligned data compression modes such as -E48bit with zstd.
Potential Impact
The vulnerability can lead to race conditions in the erofs filesystem when handling unaligned compressed extents, potentially causing data corruption or inconsistent filesystem state due to concurrent manipulation of the same managed folio. The impact is limited to scenarios using unaligned data compression in erofs and does not affect other compression modes or filesystems.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to clear the folio->private field before exposing the folio in the managed cache, preventing concurrent threads from adding the same folio multiple times. Users should update to a Linux kernel version that includes this fix. Patch status is not explicitly confirmed in the provided data; therefore, check the vendor or Linux kernel advisories for the specific fixed version and apply the update accordingly.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-22cv-hg25-xph5
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64031"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27a92a4a8d598912d21a
Added to database: 07/19/2026, 19:38:17 UTC
Last enriched: 07/19/2026, 19:57:30 UTC
Last updated: 07/20/2026, 19:41:22 UTC
Views: 12
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.