PT-2026-64637 · Linux · Linux
CVE-2026-64416
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux