{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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.",
  "id": "DEBIAN-CVE-2026-89759",
  "modified": "2026-09-12T08:47:20.413620947Z",
  "published": "2026-09-11T20:20:06.997Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-89759"
    }
  ],
  "upstream": [
    "CVE-2026-89759"
  ]
}