CVE-2026-64416 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless host
lookup_swap_cgroup_id() passes swap_cgroup_ctrl[type].map to
__swap_cgroup_id_lookup() without checking that the type was ever registered via swap_cgroup_swapon(). On a swapless host every ctrl->map is NULL, so __swap_cgroup_id_lookup() dereferences NULL + a scaled swp_offset().
Since commit bea67dcc5eea ("mm: attempt to batch free swap entries for zap_pte_range()"), zap_pte_range() -> swap_pte_batch() calls lookup_swap_cgroup_id() on any non-present, non-none PTE that decodes as a real swap entry, without first validating it against swap_info[]. A
single PTE corrupted into a type-0 swap entry takes the host down at process exit.
We hit this in production on a swapless 6.12.58 host: ~1s of "get_swap_device: Bad swap file entry 3f800204222bb" (do_swap_page() being correctly defensive about the same entry) followed by
BUG: unable to handle page fault for address: 000003f800204220 RIP: 0010: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
syzbot has reported the identical stack.
The source of the PTE corruption is a separate bug; this change makes the teardown path as robust as the fault path already is. Every other caller of lookup_swap_cgroup_id() is downstream of a get_swap_device() that has already validated the entry, so the new branch is cold.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability described represents a critical null pointer dereference in the Linux kernel's memory management subsystem specifically affecting swap cgroup functionality on systems without swap space enabled. This issue manifests when the lookup_swap_cgroup_id function attempts to access a NULL map pointer without proper validation, creating a potential system crash during process termination sequences. The flaw occurs within the mm subsystem where swap cgroup tracking mechanisms fail to properly validate swap entry types before attempting to dereference memory structures.
The technical root cause stems from a missing validation check in the lookup_swap_cgroup_id function which passes swap_cgroup_ctrl[type].map directly to __swap_cgroup_id_lookup() without verifying that the type was properly registered through swap_cgroup_swapon(). On swapless hosts, all ctrl->map entries are initialized to NULL, causing the subsequent dereference of NULL plus a scaled swp_offset() value. This condition is particularly dangerous because it can be triggered by corrupted page table entries that decode as swap entries, even when no actual swap space exists.
The operational impact of this vulnerability extends beyond simple system crashes, as it represents a denial of service vector that can bring down entire systems during normal termination sequences. The specific trigger occurs when zap_pte_range() calls swap_pte_batch() on corrupted page table entries that appear to be valid swap entries but are actually malformed. This scenario is particularly concerning because the vulnerability affects the teardown path of processes, making it a persistent threat during system operations. The issue was identified through production environments running kernel version 6.12.58 where the system exhibited brief warning messages about bad swap file entries before crashing with a page fault at lookup_swap_cgroup_id.
The fix addresses this by implementing proper validation checks that ensure swap entry types are properly registered before attempting to access their associated map structures. This change makes the teardown path robust against corrupted page table entries while maintaining backward compatibility. The solution aligns with defensive programming principles and follows established security practices for handling untrusted input data, as referenced in CWE-476 which addresses null pointer dereference vulnerabilities. The vulnerability also relates to ATT&CK technique T1490 which involves creating or manipulating system resources to cause denial of service conditions.
The complexity of this issue lies in its interaction between multiple kernel subsystems including memory management, swap handling, and page table operations. The fix specifically targets the fault path that already contained proper validation through get_swap_device() calls, but extends this protection to the teardown sequence where similar corruption could occur. This represents a classic case of incomplete validation that creates security implications in system cleanup routines, emphasizing the importance of comprehensive input validation across all code paths, particularly those involved in resource deallocation and system shutdown procedures.