CVE-2026-89759: Linux Kernel Stack Scanning DoS Vulnerability

CVE-2026-89759 Overview

CVE-2026-89759 is a Linux kernel vulnerability in the mm/kmemleak subsystem. The kmemleak_scan() function scans every task stack under a single rcu_read_lock() without any reschedule point. On hosts with a large number of threads, this loop can monopolize a CPU long enough to trip the soft lockup watchdog. Debug builds with KASAN or lockdep enabled amplify the condition. The kernel emits a BUG: soft lockup message referencing kmemleak_scan_thread and can leave the affected CPU unresponsive, degrading system stability and availability.

Critical Impact
The defect enables a denial-of-service condition on Linux hosts running many threads, triggering soft lockup watchdog warnings and CPU stalls during kernel memory leak scans.

Affected Products

Linux kernel versions containing the pre-patch kmemleak_scan() implementation
Debug-enabled builds using KASAN or lockdep are especially susceptible
Distributions shipping kernels prior to the referenced stable commits

Discovery Timeline

2026-09-11 - CVE-2026-89759 published to NVD
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-89759

Vulnerability Analysis

The defect lives in mm/kmemleak.c. The kmemleak_scan() routine iterates over every thread on the system and scans each kernel stack while holding a single RCU read-side critical section. Because RCU read sections forbid voluntary preemption, no cond_resched() call can execute inside the loop. On systems with many tasks, the scan runs long enough for the kernel's soft lockup watchdog to fire, printing a message such as watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537] with a stack trace through scan_block, kmemleak_scan, and kmemleak_scan_thread.

Root Cause

The root cause is an unbounded loop inside a non-preemptible RCU read-side critical section. The scanner acquires rcu_read_lock() once and walks the entire task list, holding the CPU for the full duration of the scan. Adding cond_resched() inside the loop is not legal because RCU read sections cannot yield.

Attack Vector

The condition is triggered locally by normal kernel activity on hosts with high thread counts. Workloads that spawn many threads increase scan duration proportionally. The vulnerability manifests as a denial-of-service through CPU stalls rather than as a remote or privilege escalation flaw. See the kernel commit history for the fix pattern.

The patch series replaces the monolithic scan with per-task iteration using find_ge_pid(). Each iteration takes the RCU read lock only long enough to look up and pin one task, releases the lock, scans that task's stack, and then calls cond_resched() before proceeding. This mirrors the next_tgid() and task_seq_get_next() iteration pattern and keeps every RCU critical section short.

Detection Methods for CVE-2026-89759

Indicators of Compromise

Kernel log entries containing watchdog: BUG: soft lockup referencing the kmemleak kthread
Stack traces including scan_block, kmemleak_scan, and kmemleak_scan_thread
Extended CPU stall durations reported by the soft lockup watchdog on hosts running many threads

Detection Strategies

Monitor dmesg and syslog for repeated soft lockup warnings attributed to the kmemleak thread
Correlate scan events with host thread counts and enabled debug features such as KASAN or lockdep
Track kernel version and patch level across the fleet to identify hosts running pre-fix builds

Monitoring Recommendations

Forward kernel ring buffer output to a centralized log platform and alert on soft lockup strings
Track CPU stall metrics and watchdog counters exposed through /proc and node exporters
Baseline kmemleak scan duration on debug builds and flag regressions

How to Mitigate CVE-2026-89759

Immediate Actions Required

Apply the upstream stable kernel updates that include the kmemleak_scan() iteration rework
Prioritize patching on debug-enabled hosts and systems with high thread counts
Disable kmemleak scanning on affected kernels where the feature is not required for diagnostics

Patch Information

The fix is distributed across the referenced stable kernel commits: commit 1838c704, commit 3fc80442, commit 5d10d4e1, and commit 9a1b12c0. The patches walk tasks one PID at a time with find_ge_pid(), drop the RCU lock before scanning each stack, and permit cond_resched() between tasks.

Workarounds

Stop periodic kmemleak scans by writing off to /sys/kernel/debug/kmemleak on affected hosts
Build production kernels without CONFIG_DEBUG_KMEMLEAK where the feature is unnecessary
Reduce concurrent thread counts on impacted workloads until patched kernels are deployed

bash

# Configuration example
# Disable kmemleak scanning at runtime on an affected kernel
echo off | sudo tee /sys/kernel/debug/kmemleak

# Verify current kernel version to confirm patch status
uname -r