CVE-2026-68337: Fix Makes TC BPF Qevent Redirects Drop Packets

The CVE record was published on August 10, 2026, with no CVSS score or NVD severity assessment. Its description documents a NULL-pointer dereference in the kernel’s BPF redirect handling when a BPF program is executed from a qdisc event path that does not establish the per-task

expected by redirect code. The practical result is a local denial of service: an eligible BPF/TC configuration can crash the kernel rather than redirect or discard a packet safely.

Upstream kernel developer Daniel Borkmann’s patch is unusually clear about the intended change: when the required context does not exist, redirect helpers now refuse to operate, and a

decision produced from the qevent route is converted into a drop. The replacement behavior is deliberately fail closed: the packet is discarded, and the machine stays up.

The crash requires a specialized TC qevent configuration​

This bug sits in the overlap between two advanced Linux networking facilities: eBPF programs attached through Traffic Control, and qdisc events, or qevents. A qdisc is the kernel object that manages packet queuing and scheduling on an interface. Qevents are attachment points that let TC filter blocks run when specified events occur inside a qdisc, such as an early-drop event.

The vulnerable route exists when a BPF filter attached to one of those qevent blocks either invokes

directly or returns

. In the first case, the helper tries to retrieve the current task’s BPF network context; in the second,

passed the redirect decision to

, which made the same unsafe assumption.

The kernel’s BPF redirect machinery uses

to retain the requested target interface and redirect flags until the packet is handled. Following a PREEMPT_RT-related rework, that state lives through a pointer in

, rather than a simple per-CPU object. Most TC BPF entry paths establish that context before running a program. The qevent route did not.

That distinction is the whole bug. The redirect code was not checking whether

existed before dereferencing it. A BPF program attached to a qevent block could therefore reach a NULL dereference with a redirect helper call, or merely by returning the redirect verdict.

The supplied proof configuration uses the RED qdisc’s

qevent and attaches a BPF object to the referenced filter block. This is a real and useful setup for network experimentation, policy enforcement, packet steering, and observability work, but it is far removed from a normal workstation’s network stack.

An attacker would need the ability to install and exercise the applicable qdisc and BPF configuration. In practice, that means substantial local networking and BPF privileges, not simply the ability to send malformed traffic to a host. The published material describes a crash and provides no evidence of code execution, privilege escalation, information disclosure, or network-reachable exploitation.

Upstream chose packet loss over a kernel panic​

The patch makes two closely connected changes.

First, the

,

, and

helper paths verify that a BPF network context is present before accessing redirect state. If it is missing, the helpers return

, the Traffic Control action that drops the packet.

Second,

no longer sends a

verdict to

. It treats that result like

: qdisc drop statistics are updated and the packet is released.

This is an intentional loss of functionality for one attachment path. Redirects from qevent-attached BPF programs will no longer be attempted. But it is not a functional regression in the practical sense, because the previous implementation did not provide a working redirection feature there; it crashed the system instead.

The kernel commit explicitly rejects the alternative design of extending

lifetime management through the qdisc event path. That is a sensible containment decision. Propagating task-specific networking context through another packet-processing path would widen the change and increase the chance of introducing new state-lifetime failures. Dropping an unsupported redirect result is smaller, easier to audit, and preserves the kernel’s availability.

The patch changes only

and

. It is accompanied by a BPF self-test for redirect attempts from a qdisc qevent block, which is important: the fix is testing both the helper-triggered and verdict-triggered cases that previously reached the unsafe dereference.

NVD’s affected-version statement does not match the code history​

The most consequential problem in the new NVD entry is its broad version assertion. The record says Linux versions from 5.9 onward are affected, while also presenting Git-based affected ranges beginning at commit

, the change that introduced qevent block helpers. Those two statements cannot both describe the vulnerable call path accurately.

The qevent support was introduced by that later commit, whose purpose was specifically to add TC block attachment points for qdisc events and the

function. Before qevent blocks existed, the vulnerable qevent execution path did not exist. A kernel cannot be vulnerable to this particular trigger merely because it is newer than Linux 5.9.

The other relevant antecedent is commit

, which introduced the task-based

mechanism that the fixed code now checks. The CVE fix itself lists both commits in its “Fixes” metadata: one created the qevent handling path, and the other changed BPF redirect state to use the per-task context.

That makes the NVD’s generic “5.9 onward” range an overstatement. Administrators should not treat every post-5.9 kernel as exposed without checking whether it contains both relevant code lines and an enabled qevent-capable TC configuration. The CVE record’s own Git ranges are more useful than its high-level semantic-version field, though even those must be interpreted alongside a distributor’s backports.

NVD currently provides no CVSS vector, base score, CWE mapping, or analyst assessment. That absence should not be read as proof of low severity, but the available technical record supports a focused availability issue in an advanced local configuration—not a general-purpose emergency for every Linux endpoint.

Linux 7.2-rc5 contains the upstream repair; stable users must check packages​

Linus Torvalds included the upstream patch in the Linux 7.2-rc5 release announced on July 26, 2026. The Linux Kernel Mailing List’s release listing and LWN.net’s coverage both list “bpf: Reject redirect helpers without a bpf_net_context,” alongside a corresponding BPF qevent self-test.

A separate stable commit,

, carries the same patch and identifies upstream commit

as its source. The CVE record associates that stable fix with the Linux 7.1 line and lists 7.1.6 as unaffected, although its version-expression formatting is imprecise enough that package-level verification remains the right operational check.

For self-built kernels, the decision is straightforward: move to a release containing the upstream fix or backport the two-file patch. For distribution kernels, do not rely solely on

. Enterprise distributions routinely backport networking fixes into kernels whose visible version number predates the upstream release that first carried the patch.

Administrators operating TC/BPF infrastructure should review:

• Systems that attach cls_bpf or act_bpf programs to qdisc qevent blocks, particularly RED qdiscs using event blocks.
• Hosts that grant tenants, containers, CI jobs, or network automation tools the privilege to alter qdiscs or attach TC BPF programs.
• Custom kernels or appliance images based on the affected qevent code but not yet incorporating the stable backport.
• Kernel package changelogs and vendor security advisories for the upstream commit 3f4920d165b2 or stable commit cabfacbd5af0.

WSL2 users should treat this as a kernel-package question, not a Windows patch issue​

Windows systems do not become vulnerable merely because they run Windows 11 or have WSL installed. This is Linux kernel code, and the relevant behavior exists only inside a Linux kernel that contains the qevent path and permits the TC/BPF setup needed to trigger it.

For WSL2, that means the relevant component is the Microsoft-supplied WSL kernel, or a custom kernel configured through WSL settings. A standard WSL distribution without privileged TC/BPF experimentation is unlikely to encounter this path. Teams using WSL2 as a local network-function development environment, especially with custom kernels and elevated container workflows, should nevertheless monitor Microsoft’s WSL kernel package updates and test the patched behavior.

The concrete operational outcome is modest but important: after patching, an unsupported redirect request from a qevent-attached BPF program drops a packet instead of taking down the host. On affected systems where that configuration is intentionally deployed, kernel updates should be scheduled as an availability fix; elsewhere, this CVE is a reminder to validate NVD version ranges against the upstream commits before turning a narrow networking defect into a fleet-wide incident.