CVE-2026-64416

What it actually does

This Linux kernel flaw is a NULL pointer dereference in the memory-management swap cgroup path. On systems without swap configured, swap_cgroup_ctrl[type].map can be NULL because no swap cgroup map was registered through swapon. A corrupted page table entry that decodes as a real swap entry can reach zap_pte_range() during memory unmapping, which calls swap_pte_batch() and then lookup_swap_cgroup_id() without first validating the swap entry against swap_info[]. The kernel then dereferences a NULL-derived address and crashes. The practical technical impact is local denial of service through a kernel panic or host crash; the described issue does not by itself provide code execution or privilege escalation.

Why it matters to the business

A vulnerable Linux host can be crashed if the vulnerable code path is reached, causing workload interruption, service downtime, failed jobs, container or VM disruption, and potential data loss for in-flight operations. The risk is highest for swapless Linux systems running affected kernels, especially where untrusted local users, containers, sandboxed workloads, or exposed services could exercise a separate memory-corruption path that creates the malformed page table entry. Current public exploitation maturity is reported as none, EPSS is very low at 0.00168, and the issue is not listed in CISA KEV, so urgency is lower than actively exploited vulnerabilities but still important for stability-sensitive production fleets.

How an attack unfolds

An attacker would need local execution or another vulnerability/bug capable of corrupting a process page table entry so that it appears to be a valid swap entry on a host that has no swap configured. When the affected process exits or its memory mappings are torn down, the kernel walks and unmaps the page tables through zap_pte_range(). The newer batching path calls swap_pte_batch(), which calls lookup_swap_cgroup_id() for the malformed swap-like entry. Because the host is swapless, the swap cgroup map for that swap type was never initialized, so lookup_swap_cgroup_id() passes a NULL map into the lookup helper. The helper dereferences the NULL-based address, producing a kernel page fault and crashing the host. In most scenarios this should be treated as a local or chained denial-of-service condition rather than a remotely exploitable standalone bug.

How to fix it

Apply the vendor kernel update that includes the fix for lookup_swap_cgroup_id() handling on swapless hosts. Because no exact fixed package versions were provided, track the advisory from the operating system or kernel vendor and upgrade to the first kernel release that contains the upstream fix for “mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless host.” Reboot into the fixed kernel after installation; merely installing the package is not sufficient. As interim risk reduction, limit untrusted local code execution, reduce exposure of multi-tenant or container workloads on affected swapless hosts, and prioritize patching systems where untrusted workloads can run. Enabling swap may avoid the exact swapless NULL-map condition but should not be treated as a primary security fix because the robust correction is in the kernel validation path.

How to confirm the fix worked

Confirm that systems are running a kernel build that includes the vendor fix, not only that updated packages are installed. Validate with the running kernel version and vendor changelog or package metadata. On source-based or custom kernels, confirm that lookup_swap_cgroup_id() or its call path now handles an unregistered swap cgroup map and returns safely when the swap type has no map. Review kernel logs after patching for absence of recurring messages such as “get_swap_device: Bad swap file entry” followed by a crash stack containing lookup_swap_cgroup_id, swap_pte_batch, and zap_pte_range. For fleet exposure checks, identify Linux hosts with affected kernel versions and no active swap devices using standard OS inventory and runtime checks such as /proc/swaps.

Typical attack path

1. Obtain the ability to run code locally, in a container, or through a workload that can trigger kernel memory-management edge cases.
2. Trigger or chain with a separate flaw that corrupts a page table entry so it decodes as a real swap entry.
3. Target a Linux host with no swap configured, where swap cgroup maps have not been initialized.
4. Cause the affected process to exit or unmap memory, invoking exit_mmap(), unmap_page_range(), zap_pte_range(), and swap_pte_batch().
5. Force lookup_swap_cgroup_id() to process the malformed swap entry with a NULL swap cgroup map.
6. Cause a kernel NULL pointer dereference and crash the host, resulting in denial of service.

How to detect it

To determine whether this was already triggered, review persistent kernel logs, system journal records, crash dumps, kdump/vmcore artifacts, hypervisor reset events, and availability monitoring around unexpected reboots or panics. Relevant Linux log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore, netconsole output, and crash dump analysis from kdump. Look for a sequence of “get_swap_device: Bad swap file entry” messages followed shortly by a kernel BUG or page fault in lookup_swap_cgroup_id. The strongest signature is a call trace containing lookup_swap_cgroup_id, swap_pte_batch, zap_pte_range, unmap_page_range, exit_mmap, and do_exit. Also check whether affected hosts were swapless at the time of the crash using configuration management records, /proc/swaps telemetry, or boot-time inventory. There are no known named threat actors or ransomware campaigns associated with this issue in the provided data; detection should focus on kernel crash artifacts rather than network indicators.

• get_swap_device: Bad swap file entry
• BUG: unable to handle page fault for address:
• RIP: 0010:lookup_swap_cgroup_id
• lookup_swap_cgroup_id+0x2b/0x60
• Call Trace:
• swap_pte_batch+0xbf/0x230
• zap_pte_range+0x4c8/0x780
• unmap_page_range+0x190/0x3e0
• exit_mmap+0xd9/0x3c0
• do_exit+0x20c/0x4b0
• mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless host

What your security team should do

• Prioritize patching swapless Linux systems that run untrusted local users, containers, CI jobs, sandboxed workloads, or internet-facing services that may process untrusted inputs.
• Verify the running kernel after maintenance windows and ensure hosts have rebooted into the fixed kernel.
• Search historical kernel logs and crash dumps for lookup_swap_cgroup_id NULL dereference signatures to identify prior unexplained host crashes.
• If patching is delayed, reduce placement of untrusted or high-risk workloads on affected swapless hosts and enforce container isolation hardening, seccomp, AppArmor/SELinux, and least privilege.
• Monitor vendor advisories for exact fixed versions for the distributions and kernel branches in use, since fixed versions were not supplied in the input.
• Treat repeated “Bad swap file entry” messages followed by kernel oops or panic as high-priority stability and potential exploitation indicators.
• Because the issue is not in KEV and has no known public exploit maturity, schedule broadly but prioritize based on workload criticality and multi-tenant exposure rather than emergency internet-facing remediation.