erofs: fix managed cache race for unaligned extents
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) ... 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.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.18.34, 7.0.11
- CVEs
- CVE-2026-64031
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 5 Nov 2026, 02:04 UTC · Revision 1
Source evidence
erofs: fix managed cache race for unaligned extents
core-osv · Original sourcePublished 19 Jul 2026, 15:39 UTC
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) ... 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.
osv:CVE-2026-64031
Kernel
Fixed versions: 6.18.34, 7.0.11
Complete source record
{
"id": "d4540b53244b658a1230e498e9573177f0efff7ce5959c8509d9bd6cf3ad3428",
"url": "https://osv.dev/vulnerability/CVE-2026-64031",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "erofs: fix managed cache race for unaligned extents",
"summary": "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) ... 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.",
"evidence": "osv:CVE-2026-64031",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.18.34",
"evidence": "/affected/1/ranges"
},
{
"value": "7.0.11",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "high",
"structured": {
"id": "CVE-2026-64031",
"aliases": [
"CVE-2026-64031"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "722f0fcdb0bb7d12a5c6d9460b9a7de1f735f36d"
},
{
"fixed": "2718cdb6db0fdbe375e61f2980aada27bafb323e"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "7361d1e3763baaf7b9349c576137851458ad38d1"
},
{
"fixed": "425d32d6288d7d845e486af9419bbedccd8c9103"
},
{
"fixed": "038166f873c4caf6e85cfd4ea0c5a5ba297b4e8b"
},
{
"fixed": "649932fc3815eda2f24eb4de4b3a5e94886ee0b9"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64031.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.15.0"
},
{
"fixed": "6.18.34"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.0.11"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64031.json"
}
}
],
"modified": "2026-10-28T02:30:41.745646219Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/038166f873c4caf6e85cfd4ea0c5a5ba297b4e8b",
"https://git.kernel.org/stable/c/2718cdb6db0fdbe375e61f2980aada27bafb323e",
"https://git.kernel.org/stable/c/425d32d6288d7d845e486af9419bbedccd8c9103",
"https://git.kernel.org/stable/c/649932fc3815eda2f24eb4de4b3a5e94886ee0b9",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64031.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-64031",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64031.json"
}
},
"related_cves": [
{
"value": "CVE-2026-64031",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 509323,
"published_at": "2026-07-19T15:39:21.609+00:00"
}