CVE-2026-64031

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix managed cache race for unaligned extents<br /> <br /> After unaligned compressed extents were introduced, the following race<br /> could occur:<br /> <br /> [Thread 1] [Thread 2]<br /> (z_erofs_fill_bio_vec)<br /> <br /> ...<br /> filemap_add_folio (1)<br /> (z_erofs_bind_cache)<br /> <br /> ..<br /> ..<br /> folio_attach_private (2)<br /> filemap_add_folio (3) again<br /> <br /> Since (1) is executed but (2) hasn&amp;#39;t been executed yet, it&amp;#39;s possible<br /> that another thread finds the same managed folio in z_erofs_bind_cache()<br /> for a different pcluster and calls filemap_add_folio() again since<br /> folio-&gt;private is still Z_EROFS_PREALLOCATED_FOLIO.<br /> <br /> Fix this by explicitly clearing folio-&gt;private before making the folio<br /> visible in the managed cache so that another pcluster can simply wait<br /> on the locked managed folio as what we did for other shared cases [1].<br /> <br /> This only impacts unaligned data compression (`-E48bit` with zstd,<br /> for example).<br /> <br /> [1] Commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of<br /> crafted images properly") was originally introduced to handle crafted<br /> overlapped extents, but it addresses unaligned extents as well.