GHSA-CR6X-J7PJ-FQ6G
Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-11 21:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-89759"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T20:20:06Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid soft lockup when scanning task stacks\n\nPatch series \"mm/kmemleak: avoid soft lockup when scanning task\", v3.\n\nkmemleak_scan() scans every task stack under one rcu_read_lock() with no\nreschedule point, which can trip the soft lockup watchdog on hosts with\nvery many threads.\n\nThat prints the following message, depending on the workload+host\nconfiguration:\n\n watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537]\n scan_block\n kmemleak_scan\n kmemleak_scan_thread\n kthread\n\nPatch 1 walks the tasks with find_ge_pid() so the scan reschedules between\ntasks\n\nPatches 2-3 let the scan loops stop early once a scan is interrupted.\n\n\nThis patch (of 3):\n\nkmemleak_scan() walks every thread and scans its kernel stack under a\nsingle rcu_read_lock() with no reschedule point. On a host with very many\nthreads -- amplified by KASAN/lockdep in debug builds -- this loop can hog\na CPU long enough to trip the soft lockup watchdog:\n\n watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537]\n scan_block\n kmemleak_scan\n kmemleak_scan_thread\n kthread\n\nA cond_resched() cannot be added directly: the loop runs inside an RCU\nread-side critical section.\n\nWalk the tasks one PID at a time with find_ge_pid(), taking the RCU read\nlock only to look up and pin each task. The stack is then scanned with no\nlock held, so cond_resched() runs between tasks and the scan stops early\non scan_should_stop(). This follows the next_tgid()/task_seq_get_next()\niteration pattern and keeps each RCU critical section short.",
"id": "GHSA-cr6x-j7pj-fq6g",
"modified": "2026-09-11T21:31:39Z",
"published": "2026-09-11T21:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89759"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1838c704bcb4fd3556cf67513c6f97a39099e35c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3fc8044251de21555fb02c365fa681bab8b0db55"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5d10d4e19e6daa487f0cd0ea6cba472325de92f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a1b12c06c192290b8479de48f66f1e75d89c4b7"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.