CVE-2026-43496

What it actually does

This flaw is a local availability vulnerability in the Linux kernel traffic-control scheduler path. When a RED qdisc has a child qdisc such as QFQ whose peek callback uses qdisc_peek_dequeued(), a parent qdisc such as TBF can first peek an skb and then cause RED to call the child qdisc's direct dequeue path instead of consuming the already-peeked skb. That inconsistent peek/dequeue sequence can leave the child state invalid and trigger a NULL pointer dereference in qfq_dequeue(), resulting in a kernel panic. The practical impact is denial of service of the affected host; confidentiality and integrity are not directly affected.

Why it matters to the business

An attacker with local access and sufficient network-administration capability, or the ability to abuse an already vulnerable traffic-control configuration, can crash affected Linux systems. This can interrupt applications, network services, container hosts, appliances, and workloads that rely on kernel traffic shaping. The issue is not listed in CISA KEV, has low EPSS, and has no reported mature public exploit in the provided data, so broad internet-scale exploitation is unlikely; however, systems that delegate CAP_NET_ADMIN or allow tenants/containers to configure qdiscs have higher operational risk.

How an attack unfolds

An attacker first obtains local execution on a Linux system or in a context that can influence kernel traffic-control configuration, typically requiring CAP_NET_ADMIN in the relevant network namespace. The attacker configures or abuses a nested qdisc hierarchy where a parent qdisc such as TBF interacts with RED, and RED has a child qdisc such as QFQ that supports the problematic peek behavior. The attacker then generates traffic that causes the parent scheduler to peek an skb from the child path and subsequently dequeue through RED. On vulnerable kernels, RED directly calls the child dequeue operation instead of qdisc_dequeue_peeked(), so the previously peeked packet state is not handled correctly. This can drive qfq_dequeue() into a NULL pointer dereference and panic the kernel, taking the host or network namespace-dependent workload offline.

How to fix it

Upgrade to a kernel package from the operating-system or appliance vendor that includes the upstream fix changing sch_red to use qdisc_dequeue_peeked() after peeked packets. Because no exact fixed versions were provided, use the vendor advisory or kernel changelog for CVE-2026-43496 and confirm the fix is present in the running kernel, not only installed on disk. If immediate patching is not possible, reduce exposure by removing vulnerable qdisc combinations, avoiding RED with QFQ children under parent qdiscs such as TBF, disabling or unloading unused sch_red/sch_qfq/sch_tbf modules where feasible, restricting CAP_NET_ADMIN from containers and untrusted users, limiting use of unprivileged network namespaces according to operational requirements, and monitoring or blocking unauthorized tc qdisc changes.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build using uname -a, package-manager metadata, and the vendor security advisory. If building from source, verify net/sched/sch_red.c contains the corrected logic that consumes peeked packets via qdisc_dequeue_peeked() rather than directly calling the child dequeue path after a peek. Check whether relevant modules are present or loaded with lsmod, modinfo, and kernel configuration. Review traffic-control state with tc -s qdisc show to determine whether RED, QFQ, or TBF qdiscs are in use. In a non-production test system, reproduce the previously vulnerable qdisc hierarchy and traffic pattern and confirm it no longer panics. After patching, reboot or otherwise ensure the fixed kernel is actually running.

Typical attack path

1. Gain local code execution on the target system, container host, appliance, or workload environment.
2. Obtain or abuse CAP_NET_ADMIN, root privileges, or an existing traffic-control configuration in the relevant network namespace.
3. Create or identify a nested qdisc hierarchy involving RED with a child qdisc such as QFQ, commonly under a parent scheduler such as TBF.
4. Generate network traffic that causes the parent qdisc to peek and then dequeue through the RED/QFQ path.
5. Trigger the invalid dequeue sequence and NULL pointer dereference in the kernel scheduler code.
6. Cause a kernel panic, service outage, reboot, or crash dump generation.

How to detect it

To determine whether this was already exploited, examine kernel logs and crash artifacts for panics or NULL pointer dereferences involving qfq_dequeue, red_dequeue, tbf_dequeue, sch_qfq, sch_red, or __qdisc_run. Relevant sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, syslog, pstore/ramoops, kdump vmcores, hypervisor reset events, and system availability monitoring around unexpected reboots. Review auditd, process accounting, shell history where appropriate, and EDR telemetry for tc qdisc commands or netlink qdisc modification events shortly before the crash. Look for creation of nested qdisc configurations containing red, qfq, and tbf. In containerized environments, review container runtime and orchestration logs for workloads granted CAP_NET_ADMIN or privileged mode before the event. Absence of these artifacts does not prove non-exploitation because a kernel panic may truncate logs unless persistent crash logging is enabled.

• KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f]
• qfq_dequeue+
• red_dequeue+
• tbf_dequeue
• __qdisc_run
• [sch_qfq]
• [sch_red]
• [sch_tbf]
• RIP: 0010:qfq_dequeue
• BUG: kernel NULL pointer dereference
• kernel panic
• tc qdisc add
• tc qdisc replace
• qdisc red
• qdisc qfq
• qdisc tbf
• RTM_NEWQDISC
• RTM_DELQDISC
• CAP_NET_ADMIN

What your security team should do

• Prioritize patching Linux systems that allow local users, containers, orchestration components, or tenants to use CAP_NET_ADMIN or configure traffic control.
• Inventory systems using RED, QFQ, or TBF qdiscs with tc -s qdisc show and focus validation on those hosts first.
• Remove CAP_NET_ADMIN from containers and service accounts unless explicitly required.
• Alert on unexpected executions of tc, ip, or other netlink-based network configuration tools by non-administrative users.
• Review audit logs for recent qdisc modifications, especially RTM_NEWQDISC activity or tc commands creating red, qfq, or tbf schedulers.
• Enable or verify crash capture such as kdump, pstore, or ramoops on high-value Linux systems to preserve evidence after kernel panics.
• If patching is delayed, replace affected qdisc hierarchies with non-vulnerable traffic-shaping configurations or disable the relevant scheduler modules where operationally safe.