{
  "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/vmscan: report RCU-tasks quiescent states in shrink_lruvec()  I am seeing some rcu_tasks stalls in the Meta fleet during reclaim.    INFO: rcu_tasks detected stalls on tasks: \t0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 \ttask:GlobalCPUThread state:R  running task  pid:2552016 tgid:2524552   Call Trace:    shrink_lruvec    mem_cgroup_iter    shrink_node    do_try_to_free_pages    try_to_free_pages    __alloc_frozen_pages_noprof    alloc_pages_noprof    pte_alloc_one    __pte_alloc    handle_mm_fault  Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels.  Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout.  Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing.  PS: This has been discussed in [1]",
  "id": "DEBIAN-CVE-2026-89753",
  "modified": "2026-09-15T08:47:33.138092808Z",
  "published": "2026-09-11T20:20:06.270Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-89753"
    }
  ],
  "upstream": [
    "CVE-2026-89753"
  ]
}