CVE-2026-89759: mm/kmemleak: avoid soft lockup when scanning task stacks
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.
kmemleakscan() scans every task stack under one rcureadlock() 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] scanblock kmemleakscan kmemleakscanthread kthread
Patch 1 walks the tasks with findgepid() so the scan reschedules between tasks
Patches 2-3 let the scan loops stop early once a scan is interrupted.
This patch (of 3):
kmemleakscan() walks every thread and scans its kernel stack under a single rcureadlock() 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] scanblock kmemleakscan kmemleakscanthread kthread
A condresched() cannot be added directly: the loop runs inside an RCU read-side critical section.
Walk the tasks one PID at a time with findgepid(), taking the RCU read lock only to look up and pin each task. The stack is then scanned with no lock held, so condresched() runs between tasks and the scan stops early on scanshouldstop(). This follows the nexttgid()/taskseqgetnext() iteration pattern and keeps each RCU critical section short.
Affected Software
Event History
Frequently Asked Questions
Which systems are most likely to encounter this issue?
Systems using kmemleak that have very many threads are affected most directly. Debug builds using KASAN or lockdep can amplify the time spent scanning and make a soft lockup watchdog report more likely.
Does exploitation require an unprivileged remote attacker?
The provided information describes a kernel scanning behavior that can hog a CPU during kmemleak scans; it does not identify a remote attack vector or specific attacker privileges. The triggering condition stated is a host with very many threads.
What is the operational impact if the issue occurs?
A kmemleak scan can run long enough without a reschedule point to trip the soft lockup watchdog. The watchdog may report a CPU stuck in kmemleak_scan and its scan thread.
What change addresses the problem?
The fix changes task traversal to use find_ge_pid() so scanning can reschedule between tasks. Related changes allow scan loops to stop early when a scan is interrupted.