CVE-2026-64031

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) <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 Software

VendorProductVersion RangeStatus
LinuxLinux7361d1e3763baaf7b9349c576137851458ad38d1 < 425d32d6288d7d845e486af9419bbedccd8c9103affected
LinuxLinux7361d1e3763baaf7b9349c576137851458ad38d1 < 038166f873c4caf6e85cfd4ea0c5a5ba297b4e8baffected
LinuxLinux7361d1e3763baaf7b9349c576137851458ad38d1 < 649932fc3815eda2f24eb4de4b3a5e94886ee0b9affected
LinuxLinux6.15affected
LinuxLinux0 < 6.15unaffected
LinuxLinux6.18.34 <= 6.18.*unaffected
LinuxLinux7.0.11 <= 7.0.*unaffected
LinuxLinux7.1 <= *unaffected

Weaknesses

References