CVE-2026-64130: Linux Kernel Information Disclosure Flaw

CVE-2026-64130 Overview

CVE-2026-64130 is a Linux kernel vulnerability in the memory allocator (mm/page_alloc) affecting Arm64 systems that use the Memory Tagging Extension (MTE). The flaw involves improper initialization of allocation tags for the huge zero folio when the kernel runs with init_on_free enabled. When user space maps the huge zero folio through a special PMD, stale tag memory from prior kernel usage remains exposed instead of being cleared. This breaks the documented guarantee in Documentation/arch/arm64/memory-tagging-extension.rst that allocation tags are zeroed on first mapping to user space. The issue was resolved by decoupling __GFP_ZEROTAGS from __GFP_ZERO in the page allocator.

Critical Impact
The huge zero folio can expose uninitialized MTE allocation tag memory to user space on Arm64 systems running with init_on_free, violating a documented kernel security guarantee and potentially leaking kernel-managed tag state.

Affected Products

Linux kernel builds targeting Arm64 with Memory Tagging Extension (MTE) support
Kernel configurations running with the init_on_free boot option enabled
Kernel code paths using the huge zero folio via PMD-mapped transparent huge pages

Discovery Timeline

2026-07-19 - CVE-2026-64130 published to NVD
2026-07-19 - Last updated in NVD database

Technical Details for CVE-2026-64130

Vulnerability Analysis

The vulnerability is an uninitialized memory use issue [CWE-908] rooted in the interaction between the __GFP_ZEROTAGS allocation flag and the init_on_free kernel feature. The __GFP_ZEROTAGS flag is set only alongside __GFP_ZERO and __GFP_SKIP_KASAN. When init_on_free is active, pages are zeroed during __free_pages_prepare() so the allocation path can skip zeroing.

However, post_alloc_hook() treats __GFP_ZEROTAGS as a signal to skip both page content clearing and tag memory clearing. For pages later mapped to user space through set_pte_at(), this behavior is safe because set_pte_at() detects PG_mte_tagged is unset and initializes tags. The huge zero folio bypasses that path: it is mapped through a PMD marked as special, so tag initialization never runs. Stale allocation tags remain visible to user space, breaking the guarantee that tags are set to zero on first user mapping.

Root Cause

The root cause is the coupling of __GFP_ZEROTAGS semantics with __GFP_ZERO inside post_alloc_hook(). When free-time zeroing satisfies the __GFP_ZERO contract, the allocator incorrectly assumes tag clearing has also been performed, even though init_on_free only clears data, not MTE tags.

Attack Vector

A local process on an Arm64 system with MTE enabled and init_on_free set can map the huge zero folio and read the associated tag memory. The exposed tags reflect whatever state the pages held before being folded into the huge zero folio, giving user space insight into kernel-side tag values it should never observe. The upstream fix decouples __GFP_ZEROTAGS from __GFP_ZERO and passes an explicit content-clearing indicator to tag_clear_highpages(), whose return value semantics were also inverted for clarity. The behavior was reproduced by adapting the check_buffer_fill Arm64 MTE selftest to use a 2 MiB region, which reported failures at subtests 17 and 18.

No public exploitation code is available for this issue. Refer to the upstream patches (Kernel Git Commit 2f2aec5, Kernel Git Commit 6a288a4, and Kernel Git Commit 738d18f1) for the exact source-level changes.

Detection Methods for CVE-2026-64130

Indicators of Compromise

No specific host-based indicators of compromise are published for this vulnerability, as exploitation leaves no distinctive artifact in logs.
Unexpected failures in the Arm64 MTE check_buffer_fill selftest, particularly subtests exercising private mappings with sync error mode, indicate vulnerable behavior on affected kernels.

Detection Strategies

Inventory Arm64 hosts and identify kernels built with MTE support that boot with the init_on_free=1 kernel parameter.
Compare running kernel versions against the fixed commits referenced in the upstream advisory to identify unpatched systems.
Run the Arm64 MTE kernel selftests, adjusted to exercise 2 MiB regions, to validate that huge zero folio tag initialization behaves correctly.

Monitoring Recommendations

Track kernel version and boot parameter drift across the Arm64 fleet using configuration management tooling.
Monitor for unexpected MTE tag-check faults in user space processes, which may correlate with stale tag exposure.
Alert on new deployments of Arm64 workloads without the upstream fix commits applied.

How to Mitigate CVE-2026-64130

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in commits 2f2aec5, 6a288a4, and 738d18f1 to affected branches.
Rebuild and redeploy Arm64 kernel images used on MTE-capable hardware once the patch is integrated.
Restart workloads that rely on transparent huge pages after the patched kernel is in place.

Patch Information

The fix decouples __GFP_ZEROTAGS from __GFP_ZERO and passes an explicit flag to tag_clear_highpages() indicating whether page content should also be cleared. The return value of tag_clear_highpages() was inverted for clearer semantics. Patches are available in Kernel Git Commit 2f2aec5, Kernel Git Commit 6a288a4, and Kernel Git Commit 738d18f1.

Workarounds

Disable init_on_free on affected Arm64 MTE systems until the patched kernel is deployed, accepting the tradeoff against free-time zeroing hardening.
Disable transparent huge pages for workloads that expose the huge zero folio to untrusted user space until the fix is applied.
Restrict execution of untrusted local code on MTE-enabled Arm64 hosts running init_on_free until patched.

bash

# Verify kernel boot parameters and THP status on Arm64 MTE hosts
cat /proc/cmdline | tr ' ' '\n' | grep -E 'init_on_free|mte'
cat /sys/kernel/mm/transparent_hugepage/enabled
uname -r