CVE-2026-64012

What it actually does

This Linux kernel flaw is a denial-of-service bug in the traffic control scheduler path, specifically involving the sch_sfb queuing discipline when it has child qdiscs such as sch_qfq and is itself used under a parent qdisc such as sch_tbf. The vulnerable path incorrectly calls a child dequeue operation after a prior peek operation, rather than consuming the skb that was already peeked. With certain nested qdisc combinations, this can leave the child scheduler state inconsistent and cause a NULL pointer dereference in qfq_dequeue(), resulting in a kernel panic or networking subsystem crash. Practical exploitation generally requires the ability to configure Linux traffic control qdiscs, typically CAP_NET_ADMIN or equivalent privileges, although systems that already expose the vulnerable qdisc hierarchy could potentially be crashed by traffic that exercises the path.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting workloads, network appliances, container hosts, routers, firewalls, load balancers, or other services that rely on kernel traffic shaping. Because exploitation is primarily a denial-of-service condition and no public exploitation is indicated by the provided data, the immediate risk is lower than remote code execution; however, the operational impact can still be significant for systems where traffic control is used in production. EPSS is low and the issue is not listed in CISA KEV, so prioritize patching based on exposure: highest for multi-tenant Linux hosts, systems allowing untrusted users network namespace or traffic-control privileges, and infrastructure using advanced qdisc configurations.

How an attack unfolds

An attacker first needs a way to influence Linux traffic control configuration or to operate inside an environment where vulnerable qdisc nesting is already present. They configure, or take advantage of, a scheduler hierarchy where a parent qdisc requests packets from sch_sfb, and sch_sfb has a child qdisc such as sch_qfq whose peek callback uses qdisc_peek_dequeued(). The parent performs a peek and sees an skb available from the child path. The vulnerable sch_sfb code then performs a direct child dequeue instead of using qdisc_dequeue_peeked() to consume the already-peeked skb. Under the right packet flow, particularly involving GSO skb handling, this mismatch causes qfq_dequeue() to operate on unexpected state and dereference a NULL pointer. The result is a kernel oops or panic, taking down the host or disrupting network service.

How to fix it

Upgrade to a Linux kernel version that includes the fix changing sch_sfb to use qdisc_dequeue_peeked() after peeked packets rather than directly calling the child dequeue path. No exact fixed package versions were provided, so obtain patched kernels from the relevant Linux distribution, vendor advisory, or upstream stable kernel channel once available. As mitigations until patching is complete, avoid using vulnerable nested qdisc combinations involving sch_sfb with child qdiscs such as sch_qfq, remove unnecessary sfb/qfq/tbf traffic-control configurations, restrict CAP_NET_ADMIN to trusted users and containers only, disable unprivileged user namespaces where they may allow users to gain network namespace control, and prevent privileged container workloads from modifying host or namespace traffic control settings unless required.

How to confirm the fix worked

Confirm the running kernel includes the upstream fix for sch_sfb dequeue handling or a vendor backport of that fix. Inventory loaded traffic-control modules and active qdisc hierarchies using commands such as `tc qdisc show`, `lsmod | grep -E 'sch_sfb|sch_qfq|sch_tbf'`, and distribution package tooling to verify the installed kernel package version. Validate that untrusted users and containers cannot obtain CAP_NET_ADMIN or alter qdisc configuration. After remediation, exercise representative traffic-shaping workloads and confirm there are no kernel oops, KASAN, NULL pointer dereference, or qfq_dequeue/sfb_dequeue crash messages in kernel logs.

Typical attack path

1. Obtain CAP_NET_ADMIN, root privileges, or equivalent control over network traffic control configuration, including through a privileged container or network namespace if permitted.
2. Create or identify a nested qdisc hierarchy involving sch_sfb with a child qdisc such as sch_qfq and a parent qdisc such as sch_tbf.
3. Generate packet traffic through the affected interface so the parent qdisc performs a peek followed by a dequeue through sch_sfb into the child qdisc.
4. Trigger the vulnerable mismatch where sch_sfb directly dequeues from the child instead of consuming the previously peeked skb.
5. Cause a NULL pointer dereference in the kernel scheduler path, producing a kernel oops, panic, or system/network-service outage.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journal entries, crash dumps, and monitoring alerts for kernel oops or panic events involving the traffic control scheduler. Key log sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, kdump/vmcore artifacts, hypervisor reset records, and endpoint telemetry showing unexpected reboots. Look for stack traces containing `qfq_dequeue`, `sfb_dequeue`, `tbf_dequeue`, `__qdisc_run`, `qdisc_peek_dequeued`, or NULL pointer dereference/KASAN messages. Also review shell history, audit logs, sudo logs, container runtime logs, and EDR telemetry for suspicious or unexpected use of `tc qdisc` commands creating `sfb`, `qfq`, or `tbf` qdisc hierarchies. Exploitation may leave no file-based artifact beyond command history, audit records, crash dumps, and kernel logs.

• KASAN: null-ptr-deref
• null-ptr-deref in range [0x0000000000000048-0x000000000000004f]
• RIP: 0010:qfq_dequeue
• qfq_dequeue+
• sfb_dequeue+
• tbf_dequeue+
• __qdisc_run+
• qdisc_peek_dequeued+
• Comm: ping
• sch_qfq
• sch_sfb
• sch_tbf
• tc qdisc add
• tc qdisc replace
• tc qdisc change
• tc qdisc add dev
• tc qdisc replace dev
• tc qdisc change dev
• qdisc sfb
• qdisc qfq
• qdisc tbf
• kind sfb
• kind qfq
• kind tbf

What your security team should do

• Identify Linux systems using traffic control, especially hosts with sch_sfb, sch_qfq, or sch_tbf loaded or configured.
• Prioritize patching for network infrastructure, container platforms, multi-tenant systems, and hosts where users or workloads may have CAP_NET_ADMIN.
• Review container and namespace policies to ensure untrusted workloads cannot configure qdiscs or retain unnecessary network administration capabilities.
• Temporarily remove or redesign nested qdisc configurations involving sch_sfb and sch_qfq where feasible until patched kernels are deployed.
• Monitor kernel logs for qfq_dequeue, sfb_dequeue, tbf_dequeue, NULL pointer dereference, KASAN, oops, or panic events.
• Track vendor kernel advisories because no exact fixed versions were provided in the input, and ensure backported fixes are applied even if kernel version numbers differ from upstream.