{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.94-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.10-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  net/sched: taprio: fix NULL pointer dereference in class dump  When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft() is called with new == NULL and stores NULL into q-\u003eqdiscs[cl - 1]. Subsequent RTM_GETTCLASS dump operations walk all classes via taprio_walk() and call taprio_dump_class(), which calls taprio_leaf() returning the NULL pointer, then dereferences it to read child-\u003ehandle, causing a kernel NULL pointer dereference.  The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user namespaces enabled, an unprivileged local user can trigger a kernel panic by creating a taprio qdisc inside a new network namespace, grafting an explicit child qdisc, deleting it, and requesting a class dump. The RTM_GETTCLASS dump itself requires no capability.   Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI  KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]  RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2478)  Call Trace:   \u003cTASK\u003e   tc_fill_tclass (net/sched/sch_api.c:1966)   qdisc_class_dump (net/sched/sch_api.c:2326)   taprio_walk (net/sched/sch_taprio.c:2514)   tc_dump_tclass_qdisc (net/sched/sch_api.c:2352)   tc_dump_tclass_root (net/sched/sch_api.c:2370)   tc_dump_tclass (net/sched/sch_api.c:2431)   rtnl_dumpit (net/core/rtnetlink.c:6864)   netlink_dump (net/netlink/af_netlink.c:2325)   rtnetlink_rcv_msg (net/core/rtnetlink.c:6959)   netlink_rcv_skb (net/netlink/af_netlink.c:2550)   \u003c/TASK\u003e  Fix this by substituting \u0026noop_qdisc when new is NULL in taprio_graft(), a common pattern used by other qdiscs (e.g., multiq_graft()) to ensure the q-\u003eqdiscs[] slots are never NULL. This makes control-plane dump paths safe without requiring individual NULL checks.  Since the data-plane paths (taprio_enqueue and taprio_dequeue_from_txq) previously had explicit NULL guards that would drop/skip the packet cleanly, update those checks to test for \u0026noop_qdisc instead. Without this, packets would reach taprio_enqueue_one() which increments the root qdisc's qlen and backlog before calling the child's enqueue; noop_qdisc drops the packet but those counters are never rolled back, permanently inflating the root qdisc's statistics.  After this change *old can be a valid qdisc, NULL, or \u0026noop_qdisc. Only call qdisc_put(*old) in the first case to avoid decreasing noop_qdisc's refcount, which was never increased.",
  "id": "DEBIAN-CVE-2026-45845",
  "modified": "2026-09-14T16:47:33.730318973Z",
  "published": "2026-05-27T11:16:23.960Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-45845"
    }
  ],
  "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-45845"
  ]
}