{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.85-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.19.6-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  mm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node  When CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during vmalloc cleanup triggers expensive stack unwinding that acquires RCU read locks.  Processing a large purge_list without rescheduling can cause the task to hold CPU for extended periods (10+ seconds), leading to RCU stalls and potential OOM conditions.  The issue manifests in purge_vmap_node() -\u003e kasan_release_vmalloc_node() where iterating through hundreds or thousands of vmap_area entries and freeing their associated shadow pages causes:    rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:   rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l   ...   task:kworker/0:17 state:R running task stack:28840 pid:6229   ...   kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299   purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299  Each call to kasan_release_vmalloc() can free many pages, and with page_owner tracking, each free triggers save_stack() which performs stack unwinding under RCU read lock.  Without yielding, this creates an unbounded RCU critical section.  Add periodic cond_resched() calls within the loop to allow: - RCU grace periods to complete - Other tasks to run - Scheduler to preempt when needed  The fix uses need_resched() for immediate response under load, with a batch count of 32 as a guaranteed upper bound to prevent worst-case stalls even under light load.",
  "id": "DEBIAN-CVE-2026-43292",
  "modified": "2026-09-14T16:47:35.272915044Z",
  "published": "2026-05-08T14:16:36.250Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-43292"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-43292"
  ]
}