CVE-2026-64130

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free<br /> <br /> __GFP_ZEROTAGS semantics are currently a bit weird, but effectively this<br /> flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN.<br /> <br /> If we run with init_on_free, we will zero out pages during<br /> __free_pages_prepare(), to skip zeroing on the allocation path.<br /> <br /> However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will<br /> consequently not only skip clearing page content, but also skip clearing<br /> tag memory.<br /> <br /> Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that<br /> will get mapped to user space through set_pte_at() later: set_pte_at() and<br /> friends will detect that the tags have not been initialized yet<br /> (PG_mte_tagged not set), and initialize them.<br /> <br /> However, for the huge zero folio, which will be mapped through a PMD<br /> marked as special, this initialization will not be performed, ending up<br /> exposing whatever tags were still set for the pages.<br /> <br /> The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state<br /> that allocation tags are set to 0 when a page is first mapped to user<br /> space. That no longer holds with the huge zero folio when init_on_free is<br /> enabled.<br /> <br /> Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to<br /> tag_clear_highpages() whether we want to also clear page content.<br /> <br /> Invert the meaning of the tag_clear_highpages() return value to have<br /> clearer semantics.<br /> <br /> Reproduced with the huge zero folio by modifying the check_buffer_fill<br /> arm64/mte selftest to use a 2 MiB area, after making sure that pages have<br /> a non-0 tag set when freeing (note that, during boot, we will not actually<br /> initialize tags, but only set KASAN_TAG_KERNEL in the page flags).<br /> <br /> $ ./check_buffer_fill<br /> 1..20<br /> ...<br /> not ok 17 Check initial tags with private mapping, sync error mode and mmap memory<br /> not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory<br /> ...<br /> <br /> This code needs more cleanups; we&amp;#39;ll tackle that next, like<br /> decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN.<br /> <br /> [akpm@linux-foundation.org: s/__GPF_ZERO/__GFP_ZERO/, per David]