GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel mm/swap: hibernation slot freed while cached corrupts unrelated processes' memory

CVSS 7.8CVE-2026-89760Kernel, userspace & hypervisorcurated

Impact

swap_free_hibernation_slot() frees a swap slot without checking whether a folio for it sits in the swap cache, so cluster readahead can leave a folio orphaned from the swap table while the offset is handed back to the allocator. Later reclaim writes that folio's stale offset over a swap table entry that now belongs to another process. The result is silent memory corruption, process crashes or data instability across unrelated userspace - exactly the failure mode that looks like flaky hardware and burns days of debugging on a long training run. Exposure is narrow: it triggers when uswsusp prepares a hibernation image, and datacenter GPU hosts normally never hibernate, so most fleets can take this on the regular kernel cadence.

Who can reach it

Local, and only on a host where hibernation (uswsusp) actually runs with swap configured. Not reachable from a tenant pod on a server that has hibernation disabled.

What to do

Pick up the stable fix that checks for a cached folio before freeing the hibernation slot (two commits linked). Requires a kernel update and a reboot per node. If your hosts never hibernate, the code path is not reached and you can wait for the next scheduled kernel roll. The record names no fixed release versions.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.