CVE-2026-45845

What it actually does

This is a local denial-of-service flaw in the Linux kernel TAPRIO traffic-control scheduler. When a TAPRIO child queuing discipline is deleted, the kernel can store a NULL pointer in the TAPRIO class array. A later class-dump request walks the TAPRIO classes and dereferences that NULL pointer in taprio_dump_class(), causing a kernel oops or panic. The issue is reachable by a user with CAP_NET_ADMIN in a network namespace on kernels built with CONFIG_NET_SCH_TAPRIO. On systems that allow unprivileged user namespaces, a local unprivileged user may be able to create the needed namespace context and trigger the crash without ordinary host-level administrative privileges. The impact is availability only; there is no known confidentiality or integrity impact from the described bug.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting workloads, network services, containers, virtualized environments, and any business process dependent on the host. The risk is highest on multi-user systems, container hosts, development platforms, CI runners, and environments where untrusted users can create user or network namespaces. EPSS is currently very low and the issue is not listed in CISA KEV, but the bug is low-complexity and locally reachable in common namespace-enabled configurations, so exposed multi-tenant Linux systems should prioritize remediation.

How an attack unfolds

An attacker first obtains local code execution on an affected Linux host. If they already have CAP_NET_ADMIN in a network namespace, or if unprivileged user namespaces are enabled and allow them to create a new user and network namespace with namespace-scoped CAP_NET_ADMIN, they configure a TAPRIO qdisc using Linux traffic-control netlink operations. They then graft an explicit child qdisc under TAPRIO, delete that child qdisc so the TAPRIO internal child pointer becomes NULL, and issue a class-dump request using RTM_GETTCLASS. During the dump, the kernel walks TAPRIO classes, calls taprio_dump_class(), receives a NULL child qdisc from taprio_leaf(), and dereferences it while reading the child handle. This causes a NULL pointer dereference and can panic or otherwise destabilize the kernel, resulting in denial of service.

How to fix it

Upgrade to a Linux kernel version that includes the TAPRIO fix which substitutes noop_qdisc when a child qdisc is removed and prevents NULL entries in TAPRIO qdisc slots. Because exact fixed package versions were not provided, use the security advisory and kernel package versions from the relevant Linux distribution or kernel vendor and confirm the fix is present in net/sched/sch_taprio.c. Where immediate patching is not possible, reduce exploitability by disabling unprivileged user namespaces where operationally feasible, restricting local shell access, limiting container capabilities, avoiding CAP_NET_ADMIN for untrusted containers or workloads, and blocking use of TAPRIO where it is not required. If the kernel is custom-built and TAPRIO is unnecessary, consider disabling CONFIG_NET_SCH_TAPRIO. Mitigations reduce exposure but do not replace applying the kernel fix.

How to confirm the fix worked

Confirm the running kernel package is updated to a vendor-fixed build or contains the upstream TAPRIO change that stores &noop_qdisc rather than NULL when taprio_graft() is called with a NULL replacement. Verify whether CONFIG_NET_SCH_TAPRIO is enabled by checking the running kernel configuration, for example through /boot/config-$(uname -r), /proc/config.gz, or vendor kernel metadata. Validate namespace exposure by checking whether unprivileged user namespaces are enabled and whether untrusted workloads can receive CAP_NET_ADMIN. After patching, a controlled regression test in a non-production environment should confirm that creating a TAPRIO qdisc, deleting a child qdisc, and dumping classes no longer produces a kernel oops. Review system logs after reboot to ensure no new taprio_dump_class, NULL pointer dereference, or sch_taprio-related kernel crash messages appear.

Typical attack path

1. Gain local code execution on an affected Linux system.
2. Create or enter a network namespace where CAP_NET_ADMIN is available; on permissive systems this may be possible through unprivileged user namespaces.
3. Use traffic-control netlink operations to create a TAPRIO qdisc on an interface inside the namespace.
4. Attach or graft an explicit child qdisc to a TAPRIO class.
5. Delete the child qdisc using RTM_DELQDISC, leaving an internal TAPRIO child qdisc slot NULL on vulnerable kernels.
6. Request a traffic-control class dump using RTM_GETTCLASS.
7. Trigger a NULL pointer dereference in the kernel TAPRIO class-dump path, causing a kernel oops or panic.

How to detect it

Look for evidence of kernel crashes or oops messages involving TAPRIO traffic control, especially taprio_dump_class(), sch_taprio.c, tc_dump_tclass, qdisc_class_dump, rtnetlink, or netlink dump paths. Primary log sources include the kernel ring buffer, system journal, syslog, crash dump infrastructure, kdump/vmcore records, hypervisor reset events, endpoint telemetry, and container runtime audit logs. Search for suspicious local execution of traffic-control tooling such as tc creating or deleting taprio qdiscs, particularly from untrusted users or containers. Audit logs may show namespace creation via unshare, clone, or setns followed by tc netlink activity. Exploitation may leave few artifacts beyond a kernel oops and reboot because the effect is a crash rather than persistent compromise. Correlate kernel crash timestamps with process accounting, auditd execve records, shell history where available, container logs, and sudo/session logs to identify the user or workload that invoked traffic-control operations before the crash.

• taprio_dump_class
• net/sched/sch_taprio.c
• KASAN: null-ptr-deref
• NULL pointer dereference
• general protection fault
• qdisc_class_dump
• tc_dump_tclass_qdisc
• tc_dump_tclass_root
• tc_dump_tclass
• taprio_walk
• taprio_leaf
• taprio_graft
• rtnl_dumpit
• netlink_dump
• rtnetlink_rcv_msg
• RTM_GETTCLASS
• RTM_DELQDISC
• kind taprio
• tc qdisc add
• tc qdisc del
• tc class show
• CONFIG_NET_SCH_TAPRIO

What your security team should do

• Prioritize patching Linux systems that allow untrusted local users, run containers, provide CI/build services, or permit unprivileged user namespaces.
• Inventory hosts running kernels with CONFIG_NET_SCH_TAPRIO enabled and identify where CAP_NET_ADMIN is granted to containers, users, or automation.
• Remove CAP_NET_ADMIN from untrusted containers and workloads unless strictly required.
• Disable unprivileged user namespaces where business requirements allow, especially on shared or multi-tenant systems.
• Monitor kernel logs for TAPRIO, traffic-control, netlink, and NULL pointer dereference crash signatures.
• Treat unexpected kernel panics or reboots following tc/qdisc activity as potentially suspicious and preserve logs for investigation.
• If patching is delayed, restrict local access and namespace creation on high-value systems until fixed kernels are deployed.