CVE-2026-53342: ARM64 Linux Kernel Page-Table Hot-Removal Cleanup Bug

Technical summary

CVE-2026-53342 addresses a resource-cleanup bug in ARM64 memory management introduced by commit 5e8eb9aeeda3, which added mandatory pagetable constructor calls (pagetable_{pte,pmd,pud,p4d}_ctor()) during page-directory mapping creation. These constructors increment NR_PAGETABLE counters, set page_type to PGTY_table, and conditionally allocate spinlocks (PTL) when ALLOC_SPLIT_PTLOCKS is defined. The corresponding pagetable_dtor() calls were never added to the hot-removal path (free_hotplug_pgtable_page()), causing: (1) page_type mismatches detected by DEBUG_VM, triggering bad_page() warnings due to page_type and _mapcount sharing the same memory union; (2) NR_PAGETABLE counter leaks; and (3) potential PTL allocation leaks. The fix calls pagetable_dtor() before freeing pages in the hot-removal path to restore symmetry. Kernels prior to v6.17 without commit 2dfcd1608f3a9 are particularly affected, though the underlying asymmetry exists across all versions with the original constructor change.

Business impact

This vulnerability primarily affects hyperscallers and data-center operators performing live memory management on ARM64 systems. Hot-removal of memory is essential for workload consolidation, maintenance windows, and cloud infrastructure optimization. In production environments running debug kernels (common in regulated or high-reliability deployments), the bug manifests as system warnings that can trigger panic handlers or monitoring alerts, causing unplanned downtime. Memory and lock leaks accumulate over repeated hot-removal cycles, degrading system stability. While not remotely exploitable, the impact is operationally significant for organizations relying on ARM64-based servers (Graviton, ThunderX, Ampere, etc.) for cloud or edge workloads.

Affected systems

The vulnerability affects the Linux kernel on ARM64 architecture systems. It is most visible on kernel versions prior to v6.17 with DEBUG_VM enabled and without commit 2dfcd1608f3a9. However, the underlying resource-cleanup asymmetry exists in all kernel versions that include commit 5e8eb9aeeda3. Affected deployments include: ARM64-based cloud instances (AWS Graviton, Azure Ampere), on-premises ARM64 servers, and edge/IoT systems performing dynamic memory management. The bug requires the ability to trigger hot-memory-removal operations, typically available only to privileged system administrators or hypervisor processes.

Exploitability

This is not exploitable for privilege escalation, information disclosure, or code execution. Exploitation requires local privilege access to trigger memory hot-removal (a privileged operation), and the resulting behavior is either benign page warnings or resource leaks—not arbitrary system compromise. The vulnerability is a reliability and correctness issue rather than a security boundary violation. Attackers cannot leverage this remotely or to elevate privileges; impact is confined to system availability and accounting accuracy.

Remediation

Apply a kernel update that includes the pagetable_dtor() call in the hot-removal path. Verify the fix is present by confirming that free_hotplug_pgtable_page() explicitly calls pagetable_dtor() before page release. For interim mitigation on affected production systems: (1) disable DEBUG_VM in kernel builds if not operationally required; (2) minimize frequent memory hot-removal cycles if possible; (3) monitor for bad_page warnings in kernel logs and correlate with memory hot-removal events. Long-term, apply vendor-provided kernel security updates targeting ARM64 memory management. Verify patch application against the upstream Linux kernel commit that resolves this issue.

Patch guidance

Locate and apply upstream Linux kernel fixes that add pagetable_dtor() to the hot-memory-removal code path. Patch candidates include backports of commit 2dfcd1608f3a9 (mm/page_alloc: let page freeing clear any set page type) and any ARM64-specific memory-management fixes dated after July 2026. Verify with your Linux distribution (Red Hat, Ubuntu, Debian, etc.) for availability of backported patches to stable or LTS kernel branches. Test patches in a non-production ARM64 environment performing repeated memory hot-removal operations to confirm no page warnings are emitted and NR_PAGETABLE counters remain stable.

Detection guidance

Search kernel logs for 'BUG: Bad page state' messages appearing in association with memory hot-removal commands (echo offline > /sys/devices/system/memory/memoryX/state or equivalent). Monitor NR_PAGETABLE counter in /proc/meminfo before and after hot-removal cycles—persistent increases indicate leaked pagetable entries. On systems with kernel tracing enabled, correlate ftrace output from the arch_remove_memory() and free_hotplug_pgtable_page() functions with page-corruption warnings. Enable CONFIG_DEBUG_VM_PGTABLE if available to trigger detection of page-table state anomalies during boot and hot-remove operations.

Why prioritize this

Although rated MEDIUM severity (CVSS 5.5), prioritization should reflect operational context: for hyperscalers and cloud providers performing routine memory optimization, this is HIGH priority due to potential impacts on service availability and the frequency of hot-removal operations. For traditional enterprise or single-instance deployments without active hot-memory management, priority is MEDIUM-LOW. The lack of security-boundary impact and remote-exploitation vector places this below critical zero-day concerns, but the reliability implications and hidden resource leaks warrant prompt remediation during the next planned kernel update cycle.

Risk score, explained

CVSS 3.1 score of 5.5 (MEDIUM) reflects: Attack Vector Local (AV:L)—requires privileged memory-management access; Attack Complexity Low (AC:L)—hot-removal is straightforward once privileged; Privileges Required (PR:L)—admin/system access mandatory; User Interaction None (UI:N)—no user action needed; Scope Unchanged (S:U)—only the local system affected. Impact: Confidentiality None (C:N), Integrity None (I:N), Availability High (A:H)—system stability, memory accounting, and log clarity are degraded. The score does not capture the operational severity for infrastructure teams; organizations depending on ARM64 hot-memory management should weight this higher in their patch-prioritization models.

Frequently asked questions