CVE-2026-53342

What it actually does

This is an ARM64 Linux kernel memory-management flaw in the memory hot-remove path. Page-table pages allocated with pagetable constructors are freed without the matching pagetable destructor, leaving page_type, page-table accounting, and optional split page-table-lock allocations in an inconsistent state. On affected kernels, especially with DEBUG_VM enabled, removing memory can trigger a kernel "Bad page state" BUG/warning and may cause system instability or denial of service. Where split page-table locks are enabled, it can also leak page-table lock allocations and corrupt NR_PAGETABLE accounting.

Why it matters to the business

The primary risk is availability loss on ARM64 Linux systems that use memory hotplug or memory hot-remove features, including virtualized, cloud, appliance, or dynamically resized environments. A local user or process that can cause memory offlining/removal may be able to crash or destabilize the host, interrupt workloads, and require operational recovery. The vulnerability is not known to be exploited in the wild, is not in CISA KEV, and has a very low EPSS score, so urgency is highest for ARM64 systems where memory hotplug is enabled or exposed through administrative automation.

How an attack unfolds

An attacker first needs local access and the ability to influence memory hot-remove operations, such as through delegated administrative tooling, privileged containers, misconfigured sudo rules, virtualization management hooks, or direct access to memory hotplug sysfs controls. The attacker causes memory to be offlined and removed on an affected ARM64 kernel. During cleanup, the kernel frees hot-removed page-table pages without calling the required pagetable destructor. This leaves stale page metadata and accounting behind; on susceptible builds this can trigger a bad page state BUG, leak page-table-lock memory, or destabilize the kernel. The result is denial of service rather than data theft or privilege escalation based on the available vulnerability details.

How to fix it

Upgrade to a vendor-supported kernel build that includes the upstream fix for calling pagetable_dtor() in free_hotplug_pgtable_page() on ARM64 hot-removed page tables. Because no exact fixed package versions were provided, use distribution advisories and kernel changelogs to confirm the backport of the fix associated with the resolved issue "arm64: mm: call pagetable dtor when freeing hot-removed page tables." If immediate patching is not possible, restrict access to memory hotplug controls, remove unnecessary delegated privileges that can write to /sys/devices/system/memory/*/state, disable or avoid memory hot-remove workflows where feasible, and limit local shell/container access on affected ARM64 hosts.

How to confirm the fix worked

Confirm that running kernels on ARM64 systems include the vendor backport or upstream fix for the hot-removed page-table destructor path. Review kernel package changelogs, distro security advisories, or source patches for free_hotplug_pgtable_page() calling pagetable_dtor(). In a staging environment, perform controlled memory offline/remove testing and verify that dmesg or journalctl does not show "BUG: Bad page state", "page_type: f2(table)", "page dumped because: nonzero mapcount", or call traces involving free_empty_tables(), __remove_pgd_mapping(), arch_remove_memory(), try_remove_memory(), or offline_and_remove_memory(). Also confirm that only trusted administrative roles can write to memory hotplug sysfs state files.

Typical attack path

1. Obtain local authenticated access to an affected ARM64 Linux system.
2. Identify that memory hotplug or memory hot-remove functionality is available.
3. Gain or abuse permission to offline/remove memory, for example through sysfs, administrative automation, virtualization tooling, or misconfigured delegated privileges.
4. Trigger repeated or targeted memory offlining/removal events.
5. Cause the kernel to free page-table pages with stale page-table metadata because the destructor is not called.
6. Induce kernel warnings, resource leakage, instability, or a host crash/reboot, resulting in denial of service.

How to detect it

To determine whether this issue was triggered, review kernel logs and persistent system journals for memory hot-remove activity followed by bad page state warnings, call traces, crashes, or unexpected reboots. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore analysis, auditd logs for writes to memory hotplug sysfs files, sudo logs, orchestration or hypervisor logs for memory resize events, and EDR telemetry for local processes writing to /sys/devices/system/memory/*/state. Focus on sequences where a memory block is offlined or removed shortly before kernel warnings mentioning nonzero mapcount, page_type table, free_hotplug_page_range, free_empty_tables, __remove_pgd_mapping, arch_remove_memory, try_remove_memory, or offline_and_remove_memory.

• BUG: Bad page state
• page dumped because: nonzero mapcount
• page_type: f2(table)
• free_hotplug_page_range
• free_empty_tables
• __remove_pgd_mapping
• arch_remove_memory
• try_remove_memory
• offline_and_remove_memory
• /sys/devices/system/memory/
• /sys/devices/system/memory/memory
• /state
• echo offline > /sys/devices/system/memory/
• echo online > /sys/devices/system/memory/
• write to /sys/devices/system/memory
• Bad page state in process

What your security team should do

• Inventory ARM64 Linux systems and determine which use memory hotplug or memory hot-remove capabilities.
• Prioritize kernel updates for ARM64 hosts that support dynamic memory resizing, virtualization, appliance workloads, or administrative workflows that can offline memory.
• Review sudo, container, orchestration, and virtualization permissions for any ability to write to /sys/devices/system/memory/*/state or otherwise trigger memory removal.
• Monitor kernel logs for bad page state warnings and memory hot-remove call traces until patching is complete.
• If patching must be deferred, disable or tightly restrict memory hot-remove operations and reduce local interactive access on affected systems.
• Because exploit maturity is currently reported as none, EPSS is low, and the issue is not KEV-listed, treat this as a targeted availability hardening item unless the environment actively uses ARM64 memory hotplug.