{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-64031","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2026-07-19T07:54:57.028Z","datePublished":"2026-07-19T15:39:21.609Z","dateUpdated":"2026-08-05T12:38:25.282Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-08-05T12:38:25.282Z"},"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix managed cache race for unaligned extents\n\nAfter unaligned compressed extents were introduced, the following race\ncould occur:\n\n[Thread 1]                                   [Thread 2]\n(z_erofs_fill_bio_vec)\n<handle a Z_EROFS_PREALLOCATED_FOLIO folio>\n...\nfilemap_add_folio (1)\n                                             (z_erofs_bind_cache)\n                                             <the same folio is found..>\n                                             ..\n                                             ..\nfolio_attach_private (2)\n                                             filemap_add_folio (3) again\n\nSince (1) is executed but (2) hasn't been executed yet, it's possible\nthat another thread finds the same managed folio in z_erofs_bind_cache()\nfor a different pcluster and calls filemap_add_folio() again since\nfolio->private is still Z_EROFS_PREALLOCATED_FOLIO.\n\nFix this by explicitly clearing folio->private before making the folio\nvisible in the managed cache so that another pcluster can simply wait\non the locked managed folio as what we did for other shared cases [1].\n\nThis only impacts unaligned data compression (`-E48bit` with zstd,\nfor example).\n\n[1] Commit 9e2f9d34dd12 (\"erofs: handle overlapped pclusters out of\n crafted images properly\") was originally introduced to handle crafted\n overlapped extents, but it addresses unaligned extents as well."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:L - The bug is reached only through local VFS read paths (`read`/`pread`/`mmap` faults) on a mounted EROFS volume, flowing through `z_erofs_read_folio`/`z_erofs_readahead` → `z_erofs_runqueue` → `z_erofs_submit_queue` → `z_erofs_fill_bio_vec` and `z_erofs_bind_cache`. There is no network-facing handler; exploitation requires local filesystem access.\nAC:L - The race is between concurrent read/decompress threads that the attacker fully controls by issuing parallel reads against a crafted image with overlapping unaligned compressed extents. No timing or layout conditions outside attacker control are required beyond crafting the image and spawning concurrent I/O.\nPR:L - Triggering the vulnerable managed-cache path requires mounting a crafted EROFS image with unaligned zstd extents, which is achievable with CAP_SYS_ADMIN inside an unprivileged user namespace (`unshare -Urn`) plus loop mount. After mount, only normal unprivileged file read access is needed to hit the race.\nUI:N - Once the attacker can mount the crafted image (e.g., via user namespace), exploitation is fully automated through concurrent reads and requires no additional victim interaction such as opening a specific application or clicking a link.\nS:U - Impact is confined to kernel memory corruption and privilege escalation within the same kernel/host security boundary; this is not a VM escape, IOMMU bypass, or cross-authority sandbox breakout.\nC:H - The race leaves managed folios visible in the page cache while `folio->private` still marks them preallocated, allowing duplicate `filemap_add_folio` and conflicting `folio_attach_private`/`folio_detach_private` bindings to different pclusters—classic page-cache corruption that can yield arbitrary kernel memory disclosure via confused folio ownership.\nI:H - Associating one managed folio with multiple pclusters corrupts `folio->private` and compressed-bvec references, creating use-after-free/refcount confusion in the managed cache that is exploitable for arbitrary kernel writes or control-flow hijack, not merely a benign error return.\nA:H - The corrupted managed-cache state can cause kernel oops/panic, hung tasks, or deadlock (similar overlapped-pcluster crafted-image failures previously caused syzbot hangs), and any successful UAF in this path also implies high availability impact even before full exploitation."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["fs/erofs/zdata.c"],"versions":[{"version":"7361d1e3763baaf7b9349c576137851458ad38d1","lessThan":"425d32d6288d7d845e486af9419bbedccd8c9103","status":"affected","versionType":"git"},{"version":"7361d1e3763baaf7b9349c576137851458ad38d1","lessThan":"038166f873c4caf6e85cfd4ea0c5a5ba297b4e8b","status":"affected","versionType":"git"},{"version":"7361d1e3763baaf7b9349c576137851458ad38d1","lessThan":"649932fc3815eda2f24eb4de4b3a5e94886ee0b9","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["fs/erofs/zdata.c"],"versions":[{"version":"6.15","status":"affected"},{"version":"0","lessThan":"6.15","status":"unaffected","versionType":"semver"},{"version":"6.18.34","lessThanOrEqual":"6.18.*","status":"unaffected","versionType":"semver"},{"version":"7.0.11","lessThanOrEqual":"7.0.*","status":"unaffected","versionType":"semver"},{"version":"7.1","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.15","versionEndExcluding":"6.18.34"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.15","versionEndExcluding":"7.0.11"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.15","versionEndExcluding":"7.1"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/425d32d6288d7d845e486af9419bbedccd8c9103"},{"url":"https://git.kernel.org/stable/c/038166f873c4caf6e85cfd4ea0c5a5ba297b4e8b"},{"url":"https://git.kernel.org/stable/c/649932fc3815eda2f24eb4de4b3a5e94886ee0b9"}],"title":"erofs: fix managed cache race for unaligned extents","x_generator":{"engine":"bippy-1.2.0"}}}}