CVE-2026-64416: mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless host
In the Linux kernel, the following vulnerability has been resolved:
mm: swapcgroup: fix NULL deref in lookupswapcgroupid on swapless host
lookupswapcgroupid() passes swapcgroupctrl[type].map to swapcgroupidlookup() without checking that the type was ever registered via swapcgroupswapon(). On a swapless host every ctrl->map is NULL, so swapcgroupidlookup() dereferences NULL + a scaled swpoffset().
Since commit bea67dcc5eea ("mm: attempt to batch free swap entries for zappterange()"), zappterange() -> swapptebatch() calls lookupswapcgroupid() on any non-present, non-none PTE that decodes as a real swap entry, without first validating it against swapinfo[]. 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 "getswapdevice: Bad swap file entry 3f800204222bb" (doswappage() being correctly defensive about the same entry) followed by
BUG: unable to handle page fault for address: 000003f800204220 RIP: 0010:lookupswapcgroupid+0x2b/0x60 Call Trace: swapptebatch+0xbf/0x230 zappterange+0x4c8/0x780 unmappagerange+0x190/0x3e0 exitmmap+0xd9/0x3c0 doexit+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 lookupswapcgroupid() is downstream of a getswapdevice() that has already validated the entry, so the new branch is cold.
Affected Software
Remediation
Event History
Frequently Asked Questions
Which systems are exposed to this crash?
Swapless Linux hosts are exposed when a corrupted page-table entry decodes as a real swap entry. The reported failure occurred on a swapless 6.12.58 host during process exit.
What does an attacker or triggering condition need to cause the denial of service?
A single corrupted PTE that appears to be a type-0 swap entry can trigger the NULL dereference. The vulnerable path is reached during process exit when page tables are unmapped.
How can I identify signs that this issue has already occurred?
Kernel logs may show repeated "get_swap_device: Bad swap file entry" messages followed by a BUG page-fault report naming lookup_swap_cgroup_id. The call trace can include swap_pte_batch, zap_pte_range, unmap_page_range, exit_mmap, and do_exit.
What should be done if patching cannot happen immediately?
The provided data identifies a patch as available, but does not provide a documented workaround. Prioritize patching swapless hosts, especially where bad swap-entry warnings or related kernel faults have been observed.