CVE-2026-89759

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.