Linux mm/swap: full-cluster reclaim runs without rescheduling and softlocks large-core-count hosts

CVSS 5.5CVE-2026-64415Kernel, userspace & hypervisorcurated

Impact

swap_reclaim_full_clusters() walks a potentially very large set of full swap clusters without ever calling cond_resched(), so the reclaim kworker can hold a CPU long enough for the watchdog to fire. The reporters hit it on a 320-CPU arm64 machine with roughly 1TB of memory under three days of sustained swap stress; with panic-on-softlockup the watchdog turns it into a kernel panic and the node is gone. The exposure is confined to hosts that actually have swap configured and drive it hard, which excludes most Kubernetes GPU nodes where swap is disabled outright, but it applies squarely to large-memory HPC and training hosts that do enable swap. No privilege boundary is crossed; this is an availability bug on the node.

Who can reach it

Local, and only on hosts with swap enabled. Any workload that can generate sustained memory pressure heavy enough to leave many full swap clusters can trigger it, so a tenant job is sufficient on a shared large-memory host.

What to do

Update to a stable kernel carrying the fix and reboot each affected node; the kernel CNA lists four stable commits and no fixed version string, so match them to your branch. Nodes running without swap are not affected and need no maintenance window for this one.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-64415 https://git.kernel.org/stable/c/2a55fdf9f746a1a6ced7fd62ea1080b8a917e0b0 https://git.kernel.org/stable/c/66366d291f666ddeda5f8c84f253e308de3e6b55 https://git.kernel.org/stable/c/69c0e6246575b780ae0d3f411c749bcf13c221f3

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.