PT-2026-61447 · Linux · Linux
CVE-2026-64130
·
Published
2026-07-19
·
Updated
2026-07-19
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
mm/page alloc: fix initialization of tags of the huge zero folio with init on free
GFP ZEROTAGS semantics are currently a bit weird, but effectively this
flag is only ever set alongside GFP ZERO and GFP SKIP KASAN.
If we run with init on free, we will zero out pages during
free pages prepare(), to skip zeroing on the allocation path.
However, when allocating with GFP ZEROTAG set, post alloc hook() will
consequently not only skip clearing page content, but also skip clearing
tag memory.
Not clearing tags through GFP ZEROTAGS is irrelevant for most pages that
will get mapped to user space through set pte at() later: set pte at() and
friends will detect that the tags have not been initialized yet
(PG mte tagged 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 init on free is
enabled.
Fix it by decoupling GFP ZEROTAGS from GFP ZERO, passing to
tag clear highpages() whether we want to also clear page content.
Invert the meaning of the tag clear highpages() return value to have
clearer semantics.
Reproduced with the huge zero folio by modifying the check buffer fill
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 KASAN TAG KERNEL in the page flags).
$ ./check buffer fill
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 GFP ZEROTAGS from GFP SKIP KASAN.
[akpm@linux-foundation.org: s/ GPF ZERO/ GFP ZERO/, per David]
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux