CVE-2026-64130 in Linux
Summary
by MITRE • 07/19/2026
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.
[[email protected]: s/__GPF_ZERO/__GFP_ZERO/, per David]
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability described represents a critical memory tagging inconsistency in the Linux kernel's memory management subsystem, specifically affecting the Arm64 Memory Tagging Extension (MTE) implementation. This issue manifests when the kernel operates with init_on_free enabled and encounters huge zero folios during page allocation processes. The core problem stems from improper handling of the __GFP_ZEROTAGS flag which is designed to control memory tagging behavior during allocation operations. When combined with init_on_free functionality, this creates a scenario where page content gets properly zeroed during deallocation through __free_pages_prepare() but the associated memory tags remain uninitialized, creating a security risk.
The technical flaw occurs because __GFP_ZEROTAGS semantics are currently intertwined with __GFP_ZERO and __GFP_SKIP_KASAN flags in an inconsistent manner. During allocation with __GFP_ZEROTAG set, the post_alloc_hook() function skips both clearing page content and clearing tag memory, which is problematic for huge zero folios. While regular pages eventually get their tags initialized through set_pte_at() when mapped to user space, huge zero folios bypass this mechanism because they are mapped through special PMD entries that do not trigger the normal tag initialization process. This creates a persistent exposure of uninitialized memory tags that could potentially leak sensitive information or create unexpected behavior in memory access patterns.
The operational impact of this vulnerability is significant for systems employing both init_on_free and MTE features, particularly affecting security-sensitive applications and kernel components that rely on proper memory tagging semantics. The flaw directly contradicts the documented behavior that allocation tags should be set to zero when pages are first mapped to user space, as specified in the arm64 memory tagging documentation. This inconsistency can lead to information disclosure through memory tagging leaks, where residual tag values from previous allocations might be accessible to user-space processes through the huge zero folio mechanism. The vulnerability was demonstrated through specific test cases involving the check_buffer_fill arm64/mte selftest, which revealed failures in tag initialization when using 2 MiB memory areas.
The fix implements a decoupling of __GFP_ZEROTAGS from __GFP_ZERO semantics by modifying the tag_clear_highpages() function to properly handle both page content clearing and tag clearing independently. This solution addresses the fundamental inconsistency by ensuring that when init_on_free is enabled, memory tags are properly initialized even for huge zero folios. The approach also involves inverting the return value semantics of tag_clear_highpages() to provide clearer operational meaning and prevent future misinterpretations. Additionally, the fix acknowledges the need for broader code cleanup to properly decouple __GFP_ZEROTAGS from __GFP_SKIP_KASAN, which represents a more comprehensive architectural improvement. This vulnerability aligns with CWE-1234 (Improper Initialization) and could be categorized under ATT&CK techniques related to privilege escalation through memory corruption or information disclosure mechanisms, specifically targeting kernel memory management components that are critical for system security and stability.
This fix resolves the inconsistency in memory tagging behavior while maintaining backward compatibility with existing kernel functionality. The solution ensures that huge zero folios properly initialize their memory tags regardless of init_on_free settings, thereby preventing potential information leakage through uninitialized tag values. The implementation follows established kernel development practices for handling memory allocation flags and maintains consistency with the documented MTE behavior specifications.