---
id: CVE-2026-64031
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]                    …
severity: high
cvss: 7.8
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
cvssSource: cna
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 722f0fcdb0bb7d12a5c6d9460b9a7de1f735f36d <
    2718cdb6db0fdbe375e61f2980aada27bafb323e
  - >-
    Linux >= 7361d1e3763baaf7b9349c576137851458ad38d1 <
    425d32d6288d7d845e486af9419bbedccd8c9103
  - >-
    Linux >= 7361d1e3763baaf7b9349c576137851458ad38d1 <
    038166f873c4caf6e85cfd4ea0c5a5ba297b4e8b
  - >-
    Linux >= 7361d1e3763baaf7b9349c576137851458ad38d1 <
    649932fc3815eda2f24eb4de4b3a5e94886ee0b9
  - Linux 6.15
published: '2026-07-19'
updated: '2026-09-14'
sourceUpdated: '2026-09-14T11:58:35.405Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-64031'
references:
  - url: 'https://git.kernel.org/stable/c/2718cdb6db0fdbe375e61f2980aada27bafb323e'
  - url: 'https://git.kernel.org/stable/c/425d32d6288d7d845e486af9419bbedccd8c9103'
  - url: 'https://git.kernel.org/stable/c/038166f873c4caf6e85cfd4ea0c5a5ba297b4e8b'
  - url: 'https://git.kernel.org/stable/c/649932fc3815eda2f24eb4de4b3a5e94886ee0b9'
tags:
  - cve.org
epss: 0.00175
epssPercentile: 0.06166
ingestedAt: '2026-09-14T15:23:07.457Z'
---

## Overview

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.

## Affected

- `Linux >= 722f0fcdb0bb7d12a5c6d9460b9a7de1f735f36d < 2718cdb6db0fdbe375e61f2980aada27bafb323e`
- `Linux >= 7361d1e3763baaf7b9349c576137851458ad38d1 < 425d32d6288d7d845e486af9419bbedccd8c9103`
- `Linux >= 7361d1e3763baaf7b9349c576137851458ad38d1 < 038166f873c4caf6e85cfd4ea0c5a5ba297b4e8b`
- `Linux >= 7361d1e3763baaf7b9349c576137851458ad38d1 < 649932fc3815eda2f24eb4de4b3a5e94886ee0b9`
- `Linux 6.15`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.