CVE-2026-64415: mm/swap: add cond_resched() in swap_reclaim_full_clusters to prevent softlockup
In the Linux kernel, the following vulnerability has been resolved:
mm/swap: add condresched() in swapreclaimfullclusters to prevent softlockup
We hit a real softlockup in an internal stress test environment. The workload was LTP memory/swap stress on a large arm64 machine, with 320 CPUs, about 1TB memory and an 8.6GB swap device. The system was under heavy load and the swap device had a large number of full clusters. The softlockup was triggered during a stress test after about 3 days.
So, add periodic condresched() calls during large fullclusters reclaim operations to prevent softlockup issues.
Detailed call trace as follow:
PID: 3817773 TASK: ffff0883bb28b780 CPU: 48 COMMAND: "kworker/48:7" #0 [ffff800080183d10] crashkexec at ffffa4c1361e5de4 #1 [ffff800080183d90] panic at ffffa4c1360d5e9c #2 [ffff800080183e20] watchdogtimerfn at ffffa4c136231fa8 ... #16 [ffff8000c4ad3cb0] swapcachedelfolio at ffffa4c1363e1614 #17 [ffff8000c4ad3ce0] trytoreclaimswap at ffffa4c1363e4bfc #18 [ffff8000c4ad3d40] swapreclaimfullclusters at ffffa4c1363e5474 #19 [ffff8000c4ad3da0] swapreclaimwork at ffffa4c1363e550c #20 [ffff8000c4ad3dc0] processonework at ffffa4c136102edc #21 [ffff8000c4ad3e10] workerthread at ffffa4c136103398 #22 [ffff8000c4ad3e70] kthread at ffffa4c13610d95c
Affected Software
Remediation
Event History
Frequently Asked Questions
Which systems are most likely to encounter this issue?
The reported case involved a large arm64 system with 320 CPUs, about 1 TB of memory, an 8.6 GB swap device, heavy load, and many full swap clusters. It occurred during LTP memory/swap stress testing after approximately three days.
What level of access is required to exploit the issue?
The CVSS vector identifies it as locally exploitable with low privileges and no user interaction required. The reported impact is availability loss through a soft lockup.
What should teams do if they identify this condition?
Apply an available patch. The supplied stable-kernel references contain patches that add periodic rescheduling during large full-cluster reclaim operations.
How might the issue appear in an affected environment?
It may manifest as a watchdog-reported soft lockup in a kworker thread during swap reclaim. The provided trace includes swap_reclaim_full_clusters, __try_to_reclaim_swap, and swap_cache_del_folio.