CVE-2026-64031

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] (zerofsfillbiovec) <handle a ZEROFSPREALLOCATEDFOLIO folio> ... filemapaddfolio (1) (zerofsbindcache) <the same folio is found..> .. .. folioattachprivate (2) filemapaddfolio (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 zerofsbindcache() for a different pcluster and calls filemapaddfolio() again since folio->private is still ZEROFSPREALLOCATEDFOLIO.

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.