From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-89759][LOW] mm/kmemleak: avoid soft lockup when scanning task stacks Date: Sat, 12 Sep 2026 03:34:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-89759 X-AL-KERNEL-Priority: LOW X-AL-KERNEL-Severity: LOW X-AL-KERNEL-Base-Severity: LOW X-AL-KERNEL-KPANIC: NO X-AL-KERNEL-ActionableScore: 2 X-AL-KERNEL-ActionableScore-Lower: 1 X-AL-KERNEL-Commit: 9a1b12c06c192290b8479de48f66f1e75d89c4b7 List-Id: CVE: CVE-2026-89759 Priority: LOW AL-KERNEL base severity: LOW KPANIC flag: NO Patch: mm/kmemleak: avoid soft lockup when scanning task stacks Commit: 9a1b12c06c192290b8479de48f66f1e75d89c4b7 Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9a1b12c06c192290b8479de48f66f1e75d89c4b7 Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89759 Analysis date: Sat, 12 Sep 2026 03:34:04 -0400 ActionableScore: 2 ActionableScore lower bound: 1 Actionable bucket: Ordinary Moderate Manual review required: NO Summary: kmemleak task stack scanning can hold a long RCU read-side section while walking many threads, causing CPU soft lockups and local denial of service on debug systems where kmemleak stack scanning is enabled. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-89759 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89759 The original announcement does not normally provide a security severity estimate, CVSS assessment, or enough information to determine whether the reported kernel bug represents a practically relevant security issue. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. It combines an autonomous classifier with LLM-assisted technical analysis and a separate ActionableScore mechanism. The purpose of this report is to prioritize Linux kernel CVEs before manual review, identify cases that require prompt investigation, and support automatic closure of issues that are unlikely to have meaningful security impact. Published priority for this report: LOW Manual review required: NO A detailed explanation of the methodology and priority rules is included at the end of this message. ====================================================================== AL-KERNEL CLASSIFICATION RESULT ====================================================================== CVE-2026-89759 LOW https://www.kernelcve.org/list/?q=CVE-2026-89759 CHECK WITH IMPACT FROM ORIG NN MODERATE Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H';**CWE-400;CWE-834;CWE-770;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L';BEST CVSS score: '4.7';DESCR 'kmemleak task stack scanning could hold one RCU read side section while walking and scanning all threads, with no reschedule point between tasks. On hosts with a very large number of threads this can keep a CPU busy long enough to trigger the soft lockup watchdog and degrade system responsiveness. For the CVSS the PR:L is used because a local user or process may be able to amplify the condition by creating many threads, while enabling and configuring kmemleak is normally an administrator or debug build choice. The issue is not network reachable and does not provide a demonstrated memory corruption or information disclosure primitive. Impact is denial of service only through CPU soft lockup, mainly on systems where CONFIG_DEBUG_KMEMLEAK and stack scanning are enabled.';NO MANUAL CHECK; ,and ActionableScore result is Ordinary Moderate (with actual score 2) YES LOCK DEADLOCK INIT LEAK UAF HARDWARE MEMORY DECREASED_TO_MODERATE_REGULAR_FROM_MODERATE7_BASED_ON_GUESSCVSS_AND_CIANNH DECREASED_TO_LOW_FROM_MODERATE_BASED_ON_ACTIONABLESCORELESSTHAN3 NO NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=2 ActionableScoreLower=1 PrimitiveClass=CLASS_C RealUAF=NO HostAdminRequired=UNKNOWN NamespaceScopedPrivilege=NO ImportantCandidate=NO ManualReview=NO AutoDowngradeAllowed=YES ## 1. ActionableScore * Raw conservative score: 1 * Conservative score: 1. No floor or cap applied. * Raw paranoid score: 2 * Paranoid score: 2. No floor or cap applied. * Final recommended bucket: **Ordinary Moderate**:: ## 2. Signal breakdown Conservative signals: * +1 Availability impact realistic. The scan can monopolize a CPU long enough to trigger the soft lockup watchdog and degrade responsiveness. * 0 Local unprivileged trigger not awarded conservatively. A local user may create many threads, but the complete practical trigger also depends on kmemleak being compiled in, enabled, and scanning task stacks. * 0 Memory corruption not awarded. The patch shows long scanning under one RCU read-side section, not UAF, OOB, double free, refcount corruption, or arbitrary write. * 0 Reliable kernel crash not awarded. The demonstrated effect is a soft lockup watchdog report and CPU hogging, not a proven panic or fatal host crash. * 0 Concrete resource leak not awarded. No persistent leaked object, missing put, or unrecoverable kernel reference is established. * 0 Race penalty not applied. This is not a timing race. * 0 Rare configuration penalty not applied in arithmetic. CONFIG_DEBUG_KMEMLEAK and stack scanning limit exposure, but this is handled as reachability uncertainty rather than a speculative negative score. Paranoid additional signal: * +1 Conditional local amplification. If kmemleak stack scanning is active, an ordinary local workload with very many threads can plausibly amplify the vulnerable long scan path. Important non-awarded signals: * Controlled reclaim not demonstrated. * Arbitrary write not demonstrated. * Information disclosure not demonstrated. * Security-boundary bypass not demonstrated. * UAF or stale object lifetime violation not established. * Extra availability point not awarded because there is no distinct persistent outage beyond CPU soft lockup behavior. ## 3. Reachability analysis The vulnerable behavior is reached by the kmemleak scan thread when task stack scanning is enabled. A local user or process may increase the likelihood of the soft lockup by creating a very large number of threads, because kmemleak_scan() previously walked all task stacks under one long RCU read-side critical section. Complete attacker reachability is not fully below-host-admin in all deployments. kmemleak generally depends on CONFIG_DEBUG_KMEMLEAK and runtime/debug configuration, and it is mostly used on debug or test kernels rather than normal production kernels. Therefore HostAdminRequired is UNKNOWN rather than YES or NO. There is no network reachability. No namespace-scoped capability is relevant to the complete trigger. No special hardware is required. No race or narrow timing window is required. The main practical prerequisite is an active kmemleak scan with stack scanning enabled. ## 4. Primitive and severity interpretation The exact primitive is CPU starvation caused by scanning all task stacks without a reschedule point while holding a long RCU read-side section. This is a Class C DoS-style condition, not memory corruption. Active structured versus fixed stale storage is not applicable because there is no stale object use. Cleanup-only versus broader active use is also not applicable. No concrete repeated release or refcount operation exists. No first lifetime operation may free an object followed by a second mutation of the same dangling reference. Demonstrated consequence is soft lockup and degraded system responsiveness. Speculative consequences beyond DoS are not supported by the patch. ImportantCandidate is NO because there is no kernel corruption, ownership violation, authorization bypass, or unresolved lifetime primitive. AutoDowngradeAllowed is YES because the issue is DoS-only, debug-feature-dependent, and lacks a meaningful exploitation primitive beyond CPU hogging. Likely operational severity is ordinary Moderate or Low-like depending on whether kmemleak is enabled in the evaluated kernel. ## 5. One-sentence report phrase kmemleak task stack scanning can hold a long RCU read-side section while walking many threads, causing CPU soft lockups and local denial of service on debug systems where kmemleak stack scanning is enabled. ## 6. Manual review recommendation NO MANUAL CHECK NEEDED Reason: the patch supports a DoS-only soft lockup with no memory corruption, no UAF, no authorization bypass, no information disclosure, and no privilege escalation primitive. ## 7. Call-site confidence Call-site confidence: high ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: mm/kmemleak: avoid soft lockup when scanning task stacks Commit: 9a1b12c06c192290b8479de48f66f1e75d89c4b7 Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9a1b12c06c192290b8479de48f66f1e75d89c4b7 Commit description: 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. Link: https://lore.kernel.org/20260615-kmemleak-stack-resched-v3-0-acecd7d7fd92@debian.org Link: https://lore.kernel.org/20260615-kmemleak-stack-resched-v3-1-acecd7d7fd92@debian.org Fixes: c4b2896 ("mm/kmemleak: rely on rcu for task stack scanning") Signed-off-by: Breno Leitao Reviewed-by: Catalin Marinas Reviewed-by: Davidlohr Bueso Reviewed-by: Lance Yang Reviewed-by: Oleg Nesterov Cc: Qian Cai Cc: SeongJae Park Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Changed files: mm/kmemleak.c Diff excerpt: Not included in this email. See the upstream URL for the full patch. Full patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9a1b12c06c192290b8479de48f66f1e75d89c4b7 ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-89759 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89759 The original CVE announcement normally does not include a security-level estimate. In particular, it may not contain a CVSS assessment, an impact level, or enough information to determine whether the reported bug is a practically relevant security issue. One purpose of this parallel CVE list is to provide that missing technical and prioritization information. The original goal of the AL-KERNEL project was to prioritize Linux kernel CVE analysis automatically before manual review. The system can also help identify non-security issues that may be suitable for automatic closure. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. The first analysis stage combines an autonomous classifier with additional LLM-based analysis. The autonomous classifier runs locally on a CPU and is based on a backpropagation neural network. Together, these mechanisms produce a technical vulnerability description, identify likely weakness types, estimate CVSS severity, and provide input for ActionableScore. Two CVSS estimates are retained because incomplete kernel vulnerability information often permits more than one defensible interpretation: Conservative CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H The Best / paranoid CVSS score: 4.7 The conservative vector represents a lower-impact interpretation. The Best/paranoid vector intentionally represents a plausible upper-bound interpretation and should not automatically be treated as demonstrated real-world impact. CVSS may also need to be adjusted for a particular Linux deployment, because actual reachability, privileges, enabled kernel configuration, hardware, namespaces, exposed device nodes, and other environmental conditions can differ significantly between systems. A separate ActionableScore mechanism evaluates practical remediation urgency. Its analysis may include reachability, attack prerequisites, subsystem exposure, memory-corruption characteristics, denial-of-service reliability, and possible confidentiality, integrity, or privilege-escalation impact. Conservative ActionableScore: 1 Paranoid ActionableScore: 2 The final base severity is taken directly from the second tab-separated field of the AL-KERNEL classification result. ActionableScore does not replace or independently override that final AL-KERNEL decision, and if ActionableScore adjusted impact level of ALKERNEL, then you would see self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7. For an AL-KERNEL result of MODERATE, this report uses the following additional presentation split: ActionableScore below 5 -> MODERATE REGULAR ActionableScore 5 or more -> MODERATE 7.0 The distinction between MODERATE REGULAR and MODERATE 7.0 makes it possible to identify Moderate issues that should receive manual analysis and fixes before lower-priority MODERATE REGULAR issues. In many cases, MODERATE REGULAR fixes may wait for a later rebase or routine update. There is one override in which MODERATE REGULAR becomes MODERATE 7.0 even when the ActionableScore is below 5. When the AL-KERNEL result contains the KPANIC flag, a MODERATE result is always presented as MODERATE 7.0. The KPANIC flag selected with few regexps without usage of AI at all, so it helps to detect cases when Kernel Crash happens and similar (to filter False-Negative results from the LLM usage). KPANIC indicates that a reliable kernel crash, kernel panic, or similarly serious kernel availability impact was identified by the classification workflow. AL-KERNEL base severity for this report: LOW KPANIC detected for this report: NO Published priority for this report (same as in Subject): LOW These results are intended to support engineering triage. They are machine-generated estimates, and cases marked for manual review should be validated by a human security engineer before final disposition. For more info read docs linked from here: https://kernelcve.org/ (and you can submit you own patch there to generate such a report for non-existant CVE-id yet). Note that in many cases this AI tool selects higher severity, than real is (means you can expect Importants instead of Moderate 7.0 or Moderates 7.0 instead of regular Moderates). If you see such cases, please use reply email interface to add additional manual analyses info to this particular CVE. And please, please, let me know when you see Lows instead of Importants or Important instead of Low (because particular for such cases I need to tune this AI tool to make it better for this one and next similar). My contact email for such notifications is alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).