GHSA-22CV-HG25-XPH5
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:31In 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) ... filemap_add_folio (1) (z_erofs_bind_cache) .. .. 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.
{
"affected": [],
"aliases": [
"CVE-2026-64031"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:43Z",
"severity": "HIGH"
},
"details": "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\u003chandle a Z_EROFS_PREALLOCATED_FOLIO folio\u003e\n...\nfilemap_add_folio (1)\n (z_erofs_bind_cache)\n \u003cthe same folio is found..\u003e\n ..\n ..\nfolio_attach_private (2)\n filemap_add_folio (3) again\n\nSince (1) is executed but (2) hasn\u0027t been executed yet, it\u0027s 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-\u003eprivate is still Z_EROFS_PREALLOCATED_FOLIO.\n\nFix this by explicitly clearing folio-\u003eprivate 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.",
"id": "GHSA-22cv-hg25-xph5",
"modified": "2026-07-20T15:31:56Z",
"published": "2026-07-19T18:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64031"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/038166f873c4caf6e85cfd4ea0c5a5ba297b4e8b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/425d32d6288d7d845e486af9419bbedccd8c9103"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/649932fc3815eda2f24eb4de4b3a5e94886ee0b9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.