CVE-2026-64416

In the Linux kernel, the following vulnerability has been resolved:

mm: swapcgroup: fix NULL deref in lookupswapcgroupid on swapless host

lookupswapcgroupid() passes swapcgroup_ctrl[type].map to __swapcgroupidlookup() without checking that the type was ever registered via swapcgroup_swapon(). 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 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 lookupswapcgroupid() is downstream of a getswap_device() that has already validated the entry, so the new branch is cold.