CVE-2026-64415: Linux Kernel Swap DoS Vulnerability

CVE-2026-64415 Overview

CVE-2026-64415 addresses a softlockup condition in the Linux kernel's memory management swap subsystem. The flaw exists in the swap_reclaim_full_clusters function within mm/swap, where long-running reclaim loops fail to yield the CPU. Under heavy swap pressure with many full clusters, the kernel worker thread can monopolize a CPU long enough to trigger the watchdog and panic the system.

The issue was reproduced in an internal stress test using LTP memory/swap workloads on a large arm64 machine with 320 CPUs, roughly 1TB of memory, and an 8.6GB swap device. The softlockup manifested after about three days of sustained load.

Critical Impact
Local workloads generating heavy swap activity can cause kernel softlockups and system panics, resulting in denial of service on affected Linux hosts.

Affected Products

Linux kernel versions containing the swap_reclaim_full_clusters code path prior to the referenced stable commits
Distributions shipping vulnerable upstream kernels
Large-memory systems using swap devices are particularly exposed

Discovery Timeline

2026-07-25 - CVE-2026-64415 published to the National Vulnerability Database (NVD)
2026-07-25 - Last updated in NVD database

Technical Details for CVE-2026-64415

Vulnerability Analysis

The vulnerability resides in the Linux kernel's swap cluster reclaim path. When the swap subsystem attempts to reclaim full clusters via swap_reclaim_full_clusters, it iterates over potentially large numbers of entries without invoking cond_resched(). On systems with substantial swap usage, this loop can execute long enough to prevent the scheduler from running other tasks on the CPU.

The kernel's soft-lockup watchdog detects that a CPU has been held by a single task beyond the configured threshold and triggers a panic. The reported call trace shows the worker thread executing swap_reclaim_work → swap_reclaim_full_clusters → __try_to_reclaim_swap → swap_cache_del_folio when the watchdog fires.

The fix adds periodic cond_resched() calls inside the reclaim loop, giving the scheduler an opportunity to preempt the worker and service other runnable tasks. This is a classic kernel [CWE-834] excessive iteration pattern rather than a memory-safety bug.

Root Cause

The root cause is missing voluntary preemption points inside a potentially long-running kernel loop. On non-preemptible or voluntary-preemption kernels, iteration over a swap device holding many full clusters can exceed the watchdog threshold before completing.

Attack Vector

Exploitation requires local workloads capable of generating sustained swap pressure on a system with a large swap device. There is no remote attack vector and no privilege escalation. The impact is denial of service through kernel panic triggered by the soft-lockup watchdog. See the upstream stable commit for the exact code changes.

No verified proof-of-concept code is available. The condition
was reproduced with LTP memory/swap stress on an arm64 host
with 320 CPUs, ~1TB RAM, and an 8.6GB swap device under sustained load.

Detection Methods for CVE-2026-64415

Indicators of Compromise

Kernel panic messages referencing watchdog_timer_fn followed by frames including swap_reclaim_full_clusters, __try_to_reclaim_swap, and swap_cache_del_folio
soft lockup - CPU#N stuck for Ns! messages in dmesg or /var/log/messages on hosts with active swap workloads
Unexpected reboots or crash dumps generated by kexec on large-memory Linux hosts under swap pressure

Detection Strategies

Parse kernel ring buffer output for the specific call chain swap_reclaim_work → swap_reclaim_full_clusters → __try_to_reclaim_swap to distinguish this issue from other softlockups
Correlate crash events with sustained high pswpin/pswpout counters from vmstat to confirm swap-driven root cause
Monitor kworker CPU consumption spikes on systems with configured swap devices

Monitoring Recommendations

Enable kdump so that softlockup panics produce a crash dump usable for post-mortem verification of the call trace
Ship kernel logs to a centralized log platform and alert on soft lockup and watchdog: strings
Track swap device utilization and full-cluster counts on large-memory hosts to identify systems most exposed to this condition

How to Mitigate CVE-2026-64415

Immediate Actions Required

Inventory Linux hosts running kernels that include the swap_reclaim_full_clusters code path and identify those with large swap devices
Apply distribution-provided kernel updates that incorporate the upstream fix as soon as they are available
Reboot affected systems after upgrade to activate the patched kernel

Patch Information

The fix adds cond_resched() calls in the swap_reclaim_full_clusters loop to prevent softlockups during large reclaim operations. Upstream stable commits are available at 2a55fdf9f746, 60cbe67d1342, 66366d291f66, and 69c0e6246575. Consume the fix through your distribution's kernel package rather than backporting manually where possible.

Workarounds

Reduce swap pressure by adding physical memory or tuning workloads that drive sustained paging
Increase the soft-lockup watchdog threshold via kernel.watchdog_thresh as a temporary measure only; this masks symptoms without addressing the underlying loop
Where feasible on affected hosts, reduce swap device size or disable swap for workloads that do not require it until the patched kernel is deployed

bash

# Temporary mitigation: raise the softlockup watchdog threshold (seconds)
# Default is 10; increase cautiously and revert after patching.
sysctl -w kernel.watchdog_thresh=30

# Verify installed kernel version after patching
uname -r

# Confirm the fix is present in the running kernel changelog
rpm -q --changelog kernel | grep -i swap_reclaim_full_clusters   # RHEL/derivatives
dpkg-query -W -f='${Version}\n' linux-image-$(uname -r)          # Debian/Ubuntu