CVE-2026-45845
Received Received - Intake
NULL Pointer Dereference in Linux Kernel TAPRIO Qdisc

Publication date: 2026-05-27

Last updated on: 2026-05-27

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-27
Last Modified
2026-05-27
Generated
2026-05-27
AI Q&A
2026-05-27
EPSS Evaluated
N/A
NVD
CVE-2026-45845
EUVD
EUVD-2026-32171
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux linux_kernel *
linux kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's TAPRIO child qdisc implementation. When a TAPRIO child qdisc is deleted, a function stores a NULL pointer into an array without proper handling. Later, when the system tries to dump class information, it dereferences this NULL pointer, causing a kernel NULL pointer dereference.

The issue can be triggered by an unprivileged local user in a network namespace with certain capabilities enabled, leading to a kernel panic. The root cause is that the code does not substitute a safe placeholder for the NULL pointer, which leads to unsafe dereferencing during control-plane dump operations.


How can this vulnerability impact me? :

This vulnerability can cause a kernel panic, effectively crashing the system. An unprivileged local user can exploit this to cause a denial of service by triggering the NULL pointer dereference in the kernel's networking subsystem.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves a NULL pointer dereference in the Linux kernel's taprio qdisc when handling RTM_GETTCLASS dump operations after deleting a TAPRIO child qdisc.

Detection can involve monitoring for kernel panics or oops messages related to taprio_dump_class or NULL pointer dereferences in the kernel logs.

Specifically, checking kernel logs (e.g., using dmesg or journalctl) for messages like "taprio_dump_class" or "null-ptr-deref" around the time of network qdisc operations may indicate exploitation attempts.

Commands to help detect this include:

  • dmesg | grep -i 'taprio_dump_class'
  • journalctl -k | grep -i 'null-ptr-deref'
  • tc qdisc show
  • Monitoring for unexpected kernel panics or crashes after network namespace or qdisc manipulations.

What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by substituting &noop_qdisc when new is NULL in taprio_graft(), preventing NULL pointer dereferences.

Immediate mitigation steps include:

  • Update the Linux kernel to a version that includes the fix for this vulnerability.
  • If updating immediately is not possible, restrict unprivileged users from creating network namespaces or manipulating taprio qdiscs by limiting CAP_NET_ADMIN capabilities.
  • Disable or avoid using the CONFIG_NET_SCH_TAPRIO feature if it is not required.
  • Monitor kernel logs for signs of exploitation attempts and kernel panics related to taprio qdisc operations.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart