CVE-2026-89759: 
Linux Kernel vulnerability analysis and mitigation

CVE-2026-89759 is a Denial of Service vulnerability in the Linux kernel's kmemleak_scan() function, caused by excessive CPU consumption when scanning task stacks on systems with a very high number of threads. The function iterates over all threads under a single rcu_read_lock() with no reschedule point, allowing the loop to monopolize a CPU long enough to trigger the soft lockup watchdog. Affected kernel versions begin at commit c4b28963fd79457315783b3b0f21c01eb88cfdc1 (from Linux 5.10 onward); fixed versions include 6.12.109, 6.18.50, 7.2.4, and 7.3-rc1. The vulnerability was disclosed on September 11, 2026, and is rated Medium severity by Feedly's CVSS category estimate (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-1050 (Excessive Platform Resource Consumption within a Loop). The kmemleak_scan() function in mm/kmemleak.c walks every thread and scans its kernel stack inside a single RCU read-side critical section, preventing the insertion of cond_resched() calls that would yield the CPU. On hosts with very many threads — particularly amplified by debug instrumentation such as KASAN or lockdep — this unbounded loop can hold a CPU for over 22 seconds, triggering the soft lockup watchdog with the trace: scan_block → kmemleak_scan → kmemleak_scan_thread → kthread. The fix refactors the iteration to use find_ge_pid(), acquiring the RCU lock only briefly per task and scanning each stack without holding any lock, allowing cond_resched() to run between tasks (GitHub Advisory, Red Hat Bugzilla).

Successful exploitation causes a Denial of Service: CPU cores can stall for extended periods (observed at 22+ seconds), disrupting overall system responsiveness and potentially causing the kmemleak scanning thread to appear permanently stuck. The impact is limited to availability — there is no evidence of confidentiality or integrity compromise. The condition is most severe on high-thread-count servers and debug-instrumented kernels (KASAN/lockdep enabled), where the loop duration is significantly amplified (GitHub Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date. The vulnerability requires local access and the ability to create a large number of threads to trigger the soft lockup condition. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no EPSS score or threat actor attribution is currently available (GitHub Advisory, Red Hat Bugzilla).

• Logs: Kernel log (dmesg / /var/log/kern.log) entries containing watchdog: BUG: soft lockup - CPU#XX stuck for XXs! [kmemleak:537] with a stack trace showing scan_block → kmemleak_scan → kmemleak_scan_thread → kthread.
• Process: The kmemleak kernel thread appearing unresponsive or consuming 100% of a single CPU core for extended periods.
• System Behavior: Sudden degradation in system responsiveness on high-thread-count workloads, particularly on kernels with KASAN or lockdep enabled.

Apply the upstream kernel patch that modifies kmemleak_scan() to iterate tasks one PID at a time using find_ge_pid(), enabling reschedule points between tasks. Fixed versions are 6.12.109, 6.18.50, 7.2.4, and 7.3-rc1. As a workaround, disable kmemleak if it is not required in your environment (it is typically only enabled in debug/development kernels), or limit the maximum number of threads on the system. Patch commits are available in the stable kernel tree (GitHub Advisory, Red Hat Bugzilla).

Red Hat has opened a security tracking bug (Bug 2532495) and assigned it medium priority/severity, with 15 users CC'd indicating active internal triage. No notable public researcher commentary or broader media coverage has been identified at this time (Red Hat Bugzilla).