CVE-2026-89759

mm/kmemleak: avoid soft lockup when scanning task stacks

Published Sep 11, 2026 CVSS 3.1 · 4.7 Medium EPSS < 1% KEV · Not listed
Description
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.

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
Ubuntu USN Ubuntu USN USN-9019-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-9020-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9022-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9023-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9024-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9025-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9026-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-9039-1 Linux kernel (Azure CVM) vulnerabilities
Ubuntu USN Ubuntu USN USN-9040-1 Linux kernel (Low Latency NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-9066-1 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-9091-1 Linux kernel (NVIDIA Tegra) vulnerabilities
History
Type Values Removed Values Added
Weaknesses CWE-770
Type Values Removed Values Added
Weaknesses CWE-1050
References
Metrics threat_severity

None

cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Type Values Removed Values Added
Weaknesses CWE-770
Type Values Removed Values Added
Description 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.
Title mm/kmemleak: avoid soft lockup when scanning task stacks
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References
Weaknesses

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Oct 30, 2026, 12:32 PM
Reserved
Sep 11, 2026, 7:38 PM
Status
Received
Published
Sep 11, 2026, 8:20 PM
Modified
Oct 30, 2026, 1:20 PM
Severity
Moderate
Public date
Sep 11, 2026, 7:47 PM