CVE-2026-64415

What it actually does

This Linux kernel flaw is a denial-of-service condition in the swap subsystem. During reclamation of large numbers of full swap clusters, the kernel worker can remain in a long-running loop without yielding the CPU. On large or heavily loaded systems with significant swap activity, this can trigger the kernel watchdog soft lockup detector and may lead to a panic, crash dump, reboot, or prolonged system unresponsiveness. The issue is resolved by adding periodic scheduling points, such as cond_resched(), during swap_reclaim_full_clusters processing so other kernel work can run.

Why it matters to the business

Successful triggering can make affected Linux systems unstable or unavailable, interrupting applications, virtual machines, containers, databases, and other workloads running on those hosts. The risk is highest for large-memory systems, systems under sustained memory pressure, and hosts that actively use swap. This CVE is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and currently has no known public exploit maturity, so urgency is primarily driven by exposure of critical Linux hosts to heavy local workloads rather than widespread remote exploitation.

How an attack unfolds

An attacker generally needs the ability to run code or influence workloads on a Linux system, such as through a local shell, compromised application, container workload, batch job, or multi-tenant compute environment. The attacker creates sustained memory pressure and swap churn until the system accumulates many full swap clusters. They then continue forcing swap allocation and reclamation activity so kernel swap reclaim work runs for an extended period. On vulnerable kernels, the reclaim path may fail to yield the CPU for long enough that the watchdog detects a soft lockup. Depending on kernel configuration and operational settings, this may result in a kernel panic, crash dump, reboot, hung worker thread, severe performance degradation, or host outage.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the fix adding periodic rescheduling in the swap_reclaim_full_clusters path. Because no exact fixed package versions were provided, use vendor advisories, distribution security trackers, or kernel changelogs for the specific kernel stream in use. Where immediate patching is not possible, reduce risk by limiting untrusted local workload execution, enforcing memory and swap limits for containers and batch jobs, reducing swap dependence on critical hosts, increasing monitoring for memory pressure and soft lockups, and scheduling maintenance reboots for systems showing repeated swap-related watchdog warnings. Avoid treating swap tuning alone as a complete fix; it is a mitigation, not remediation.

How to confirm the fix worked

Confirm exposure by inventorying Linux kernel versions across servers, appliances, container hosts, and virtualized environments, then comparing them with vendor advisories that include the swap_reclaim_full_clusters softlockup fix. Validate remediation by checking the installed and running kernel after reboot, not just the installed package. Review kernel changelogs or vendor errata for the mm/swap fix involving cond_resched() in swap_reclaim_full_clusters. Operationally, confirm that affected systems no longer produce watchdog soft lockup messages referencing swap reclaim functions under memory and swap stress testing. For high-value systems, run controlled memory/swap pressure tests in staging only; do not perform destructive stress testing on production hosts.

Typical attack path

1. Gain the ability to run or influence a workload on a Linux host, container host, or multi-tenant compute node.
2. Generate sustained memory pressure using memory allocation, page fault, and swap-heavy activity.
3. Force the host to rely heavily on swap so the swap device accumulates many full clusters.
4. Trigger continued swap reclaim processing through allocation pressure and swap churn.
5. Cause swap_reclaim_full_clusters to run long enough without voluntarily yielding the CPU.
6. Trigger watchdog soft lockup detection, potentially causing a kernel panic, reboot, crash dump, or system unresponsiveness.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs, system journals, crash dumps, hypervisor console logs, hardware management logs, and monitoring platforms. Relevant artifacts include watchdog soft lockup messages, kernel panics, crash_kexec activity, unexpected reboots, and stack traces involving swap_reclaim_full_clusters, swap_reclaim_work, __try_to_reclaim_swap, swap_cache_del_folio, kworker threads, or worker_thread. Correlate these events with sustained memory pressure, high swap utilization, container or batch workloads consuming large memory, and repeated page-in/page-out activity. Since exploitation requires causing local resource exhaustion rather than sending a distinctive network payload, detection should focus on host telemetry and workload behavior rather than network indicators. Investigate whether suspicious users, compromised processes, containers, or scheduled jobs were running memory stress tools or abnormal allocation loops before the soft lockup.

• watchdog: BUG: soft lockup
• BUG: soft lockup
• softlockup
• watchdog_timer_fn
• swap_reclaim_full_clusters
• swap_reclaim_work
• __try_to_reclaim_swap
• swap_cache_del_folio
• __crash_kexec
• kernel panic
• Kernel panic
• panic at
• COMMAND: "kworker
• worker_thread
• kthread
• Out of memory
• oom-killer
• kswapd
• stress-ng
• stress --vm
• LTP memory/swap stress

What your security team should do

• Prioritize patching large-memory Linux hosts, virtualization platforms, container nodes, batch-processing clusters, and systems that regularly experience memory pressure or swap usage.
• Inventory running kernel versions and map them to vendor-fixed releases; ensure systems are rebooted into the fixed kernel after patch installation.
• Review observability data for soft lockups, kernel panics, unexpected reboots, and crash dumps involving swap reclaim functions since publication.
• Apply resource controls for untrusted workloads, including memory limits, swap limits, cgroup controls, and container runtime constraints.
• Reduce operational reliance on swap for critical services where feasible, and alert on sustained swap-in/swap-out activity combined with CPU watchdog warnings.
• Because this is not KEV-listed, not ransomware-associated, and has very low EPSS, handle as important stability remediation rather than an emergency internet-facing remote-code-execution response unless local multi-tenant abuse is a realistic threat model.