Cloudanix VulnDB

CVE-2026-89759

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel memory-checking feature can freeze the entire system for many seconds when there are thousands of running programs.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

kmemleak_scan holds a single RCU read lock while walking every task stack with no reschedule point, allowing the loop to run long enough on hosts with many threads to trip the soft lockup watchdog.

Why it matters to the business

Systems can become temporarily unresponsive or trigger watchdog-induced resets, reducing availability on high-thread-count or debug-enabled hosts.

How an attack unfolds

An attacker or workload that creates a large number of threads can cause kmemleak_scan to hold a CPU for tens of seconds during its RCU-protected iteration, resulting in a soft lockup without any code execution or privilege escalation.

How to fix it

Apply the upstream fix that replaces the single RCU critical section with per-task find_ge_pid lookups, allowing cond_resched between tasks and early exit on scan_should_stop.

How to confirm the fix worked

Boot a kernel containing the fix, run a workload that creates thousands of threads, enable kmemleak, and confirm the scan completes without soft lockup messages or excessive CPU hold times.

Typical attack path

  1. Create or induce a high thread count on the target host
  2. Trigger or wait for kmemleak_scan to run
  3. Observe CPU stall and soft lockup watchdog message referencing kmemleak_scan

How to detect it

Search kernel logs and dmesg for soft lockup watchdog entries that mention kmemleak_scan, scan_block, or kmemleak_scan_thread.

  • watchdog: BUG: soft lockup.*kmemleak
  • scan_block.*kmemleak_scan
  • kmemleak_scan_thread

What your security team should do

  • Update to a kernel release that includes the three-patch series
  • Disable kmemleak on production systems where memory-leak debugging is not required
  • Monitor kernel logs for soft lockup messages containing kmemleak_scan

The record

In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid soft lockup when scanning task stacks Patch series "mm/kmemleak: avoid soft lockup when scanning task", v3. kmemleak_scan() scans every task stack under one rcu_read_lock() with no reschedule point, which can trip the soft lockup watchdog on hosts with very many threads. That prints the following message, depending on the workload+host configuration: watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537] scan_block kmemleak_scan kmemleak_scan_thread kthread Patch 1 walks the tasks with find_ge_pid() so the scan reschedules between tasks Patches 2-3 let the scan loops stop early once a scan is interrupted. This patch (of 3): kmemleak_scan() walks every thread and scans its kernel stack under a single rcu_read_lock() with no reschedule point. On a host with very many threads -- amplified by KASAN/lockdep in debug builds -- this loop can hog a CPU long enough to trip the soft lockup watchdog: watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537] scan_block kmemleak_scan kmemleak_scan_thread kthread A cond_resched() cannot be added directly: the loop runs inside an RCU read-side critical section. Walk the tasks one PID at a time with find_ge_pid(), taking the RCU read lock only to look up and pin each task. The stack is then scanned with no lock held, so cond_resched() runs between tasks and the scan stops early on scan_should_stop(). This follows the next_tgid()/task_seq_get_next() iteration pattern and keeps each RCU critical section short.

Affected packages

Ecosystem Package Introduced Fixed