CVE-2026-64130: mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free

In the Linux kernel, the following vulnerability has been resolved:

mm/pagealloc: fix initialization of tags of the huge zero folio with initonfree

GFPZEROTAGS semantics are currently a bit weird, but effectively this flag is only ever set alongside GFPZERO and GFPSKIPKASAN.

If we run with initonfree, we will zero out pages during freepagesprepare(), to skip zeroing on the allocation path.

However, when allocating with GFPZEROTAG set, postallochook() will consequently not only skip clearing page content, but also skip clearing tag memory.

Not clearing tags through GFPZEROTAGS is irrelevant for most pages that will get mapped to user space through setpteat() later: setpteat() and friends will detect that the tags have not been initialized yet (PGmtetagged not set), and initialize them.

However, for the huge zero folio, which will be mapped through a PMD marked as special, this initialization will not be performed, ending up exposing whatever tags were still set for the pages.

The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state that allocation tags are set to 0 when a page is first mapped to user space. That no longer holds with the huge zero folio when initonfree is enabled.

Fix it by decoupling GFPZEROTAGS from GFPZERO, passing to tagclearhighpages() whether we want to also clear page content.

Invert the meaning of the tagclearhighpages() return value to have clearer semantics.

Reproduced with the huge zero folio by modifying the checkbufferfill arm64/mte selftest to use a 2 MiB area, after making sure that pages have a non-0 tag set when freeing (note that, during boot, we will not actually initialize tags, but only set KASANTAGKERNEL in the page flags).

$ ./checkbufferfill 1..20 ... not ok 17 Check initial tags with private mapping, sync error mode and mmap memory not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory ...

This code needs more cleanups; we'll tackle that next, like decoupling GFPZEROTAGS from GFPSKIPKASAN.

[akpm@linux-foundation.org: s/GPFZERO/GFPZERO/, per David]