CVE-2026-45845: net/sched: taprio: fix NULL pointer dereference in class dump
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->qdiscs[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->handle,
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:
<TASK>
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)
</TASK>
Fix this by substituting &noop_qdisc when new is NULL in
taprio_graft(), a common pattern used by other qdiscs (e.g.,
multiq_graft()) to ensure the q->qdiscs[] 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 &noop_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 &noop_qdisc.
Only call qdisc_put(*old) in the first case to avoid decreasing
noop_qdisc's refcount, which was never increased.
Security readout for executives and security teams
Plain-English summary
This Linux kernel bug can let a local user crash a vulnerable system in specific networking configurations. It affects TAPRIO traffic scheduling and becomes more concerning on systems that allow unprivileged user namespaces. The available evidence supports denial of service, not data theft or remote compromise.
Executive priority
Treat this as a reliability risk for Linux hosts, especially shared or containerized environments. It is not currently documented as actively exploited, but a local denial-of-service path against the kernel justifies timely patching in normal maintenance windows, faster for multi-tenant systems.
Technical view
TAPRIO can store a NULL child qdisc after RTM_DELQDISC. Later RTM_GETTCLASS class dumping dereferences that NULL pointer in taprio_dump_class(), causing a kernel fault. The fix substitutes noop_qdisc and adjusts enqueue/dequeue checks and refcount handling.
Likely exposure
Linux systems are exposed if they run an affected kernel with CONFIG_NET_SCH_TAPRIO enabled. Practical exposure is higher on multi-user or container-capable hosts where unprivileged user namespaces are enabled or users can obtain namespace-scoped CAP_NET_ADMIN.
Exploitation context
The source bundle says KEV is false and provides no active exploitation evidence. Triggering requires local interaction with network scheduling controls. With unprivileged user namespaces enabled, an unprivileged local user may be able to cause a kernel panic.
Researcher notes
The evidence identifies a NULL pointer dereference, not privilege escalation. The vulnerable path combines TAPRIO child qdisc deletion and later class dumping. Validate exposure through kernel configuration, namespace policy, and vendor backports rather than assuming every Linux system is affected.
Mitigation direction
Update to a kernel build containing the referenced stable TAPRIO fixes.
Prioritize shared, multi-tenant, container, and developer hosts first.
Review whether unprivileged user namespaces are necessary on exposed systems.
Check distribution vendor advisories for backported kernel package names.
Avoid direct wrangler or unrelated deployment actions; this is host kernel remediation.
Validation and detection
Inventory kernels and confirm whether CONFIG_NET_SCH_TAPRIO is enabled.
Check whether unprivileged user namespaces are enabled on Linux hosts.
Confirm vendor kernel packages include the referenced TAPRIO fix commits.
Review local users, containers, and workloads with CAP_NET_ADMIN in network namespaces.
Monitor for kernel oops or panic traces referencing taprio_dump_class.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-45845 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 27, 2026, 09:24 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.