CVE-2026-89759mm/kmemleak: avoid soft lockup when scanning task stacks
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 19, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from c4b28963fd79457315783b3b0f21c01eb88cfdc1 before 9a1b12c06c192290b8479de48f66f1e75d89c4b7; from c4b28963fd79457315783b3b0f21c01eb88cfdc1 before 3fc8044251de21555fb02c365fa681bab8b0db55; from c4b28963fd79457315783b3b0f21c01eb88cfdc1 before 1838c704bcb4fd3556cf67513c6f97a39099e35c; from c4b28963fd79457315783b3b0f21c01eb88cfdc1 before 5d10d4e19e6daa487f0cd0ea6cba472325de92f9 | CNA record |
References
- https://git.kernel.org/stable/c/9a1b12c06c192290b8479de48f66f1e75d89c4b7
- https://git.kernel.org/stable/c/3fc8044251de21555fb02c365fa681bab8b0db55
- https://git.kernel.org/stable/c/1838c704bcb4fd3556cf67513c6f97a39099e35c
- https://git.kernel.org/stable/c/5d10d4e19e6daa487f0cd0ea6cba472325de92f9
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.