CVE-2026-64530: Linux Kernel Fix Stops RED TC Use-After-Free

Linux administrators and security teams have a newly documented kernel networking flaw to account for in CVE-2026-64530, a critical use-after-free vulnerability in the Linux traffic-control subsystem. The bug occurs in an unusual but meaningful combination of features: the RED queueing discipline, qevents, a Traffic Control (TC) filter block, and the connection-tracking ct action processing out-of-order IP fragments. Kernel.org assigned the issue a CVSS 3.1 score of 9.8 Critical with a network attack vector and no required privileges or user interaction, although real-world exposure depends heavily on whether the affected traffic-control configuration exists on a target system. NVD’s CVE record identifies the fault as resolved upstream and documents the affected net/sched/cls_api.c code path.
The patch is small: when classification returns TC_ACT_CONSUMED, the queue-event handler now returns NULL and marks the packet as stolen rather than continuing to operate on it. The security significance, however, is much larger than the diff suggests. This is a classic kernel ownership error: one component has taken control of a packet buffer, while another continues to enqueue it, drop it, or account for it as though it remained valid. That mismatch can create a use-after-free condition in a highly privileged part of the operating system. The upstream commit explicitly identifies the issue as a use-after-free and attributes the report to the Zero Day Initiative.
For Windows users, this is principally a Linux infrastructure and WSL-adjacent security story, not a Windows kernel vulnerability. It matters to organizations using Linux gateways, virtual appliances, Kubernetes worker nodes, routers, firewall hosts, Linux-based network appliances, or development systems that use advanced tc configuration. It also deserves attention from enterprises running Windows endpoints alongside Linux networking workloads, because the vulnerable component can sit in the infrastructure that carries, filters, shapes, or inspects traffic for those endpoints.

---

Overview: A Packet Ownership Bug in Linux Traffic Control​

CVE-2026-64530 is rooted in the Linux networking subsystem’s treatment of sk_buff structures, commonly shortened to SKBs. An SKB is the kernel object used to represent and manage a network packet as it travels through the Linux networking stack. Its lifecycle is carefully controlled because it can be queued, cloned, redirected, transformed, retained for later work, or freed.
The flaw arises when tcf_classify returns the action result TC_ACT_CONSUMED. In that state, the packet has been retained by the defragmentation engine and is no longer owned by the caller. The caller must not enqueue, free, alter, or otherwise touch the SKB after that point. The CVE description specifically cites the act_ct connection-tracking action acting on out-of-order fragments as one situation in which the packet can be consumed. NVD’s description makes clear that the dangerous condition is not merely a failed classification decision, but a change in packet ownership.
Before the fix, tcf_qevent_handle did not contain a case for TC_ACT_CONSUMED. The result fell through the switch logic and returned the packet to the calling code as though processing had succeeded normally. That meant downstream code could behave as if it still possessed a valid SKB even when the defragmentation engine had already taken responsibility for it. The upstream patch diff shows that the correction adds a dedicated TC_ACT_CONSUMED branch that sets __NET_XMIT_STOLEN and returns NULL.
This is not an abstract memory-safety issue. The vulnerable caller is red_enqueue, the packet enqueue path for Linux’s Random Early Detection queueing discipline. Under affected conditions, RED could continue handling a packet it no longer owned: potentially enqueueing it, dropping it, or modifying traffic statistics. The documented outcome is a use-after-free condition. NVD states that these operations occurred after ownership had been lost.

Why RED, Qevents, and TC Filters Matter​

The narrow trigger conditions are important. Linux Traffic Control is a broad framework used to classify traffic, apply actions, schedule packets, shape bandwidth, manage queue pressure, and enforce policy. Many Linux systems use tc for ordinary shaping or QoS. Far fewer use the exact configuration path involved in this vulnerability.

RED is a congestion-management queueing discipline​

RED, short for Random Early Detection, is a classless queueing discipline designed to manage congestion before a queue becomes completely full. Rather than relying solely on tail drops when the queue limit is reached, RED calculates an average queue size and begins probabilistically marking or dropping packets as congestion increases. The tc-red(8) documentation explains that RED’s objective is to avoid sudden synchronized retransmissions and preserve small queues, which can help interactive traffic.
In an ECN-enabled deployment, RED can mark eligible packets to signal congestion rather than immediately dropping them. Without ECN capability, or where configured policy calls for it, the same mechanism may result in packet drops. RED is therefore a legitimate tool in high-throughput, latency-sensitive, or carefully tuned network environments. The RED manual page describes its configurable marking probability, thresholds, ECN behavior, and hard queue limit.
The CVE does not mean every machine using RED is automatically exposed. It means that RED is the currently identified queueing discipline that connects the relevant qevent handling mechanism to packet processing in this vulnerable path. In the present implementation, the qevent integration is what turns a subtle ownership bug into an actionable memory-safety issue. NVD says RED is the only qdisc currently wired to qevents through the cited call sites.

Qevents attach programmable policy to queue events​

A qevent allows a queueing discipline to invoke a user-configured filter block when something significant occurs in the queue. For example, a queue can expose an event for an early drop or an ECN mark, then allow Traffic Control filters and actions to run in response. The tc(8) manual describes qevents as attachment points where qdiscs invoke configured actions when specific events take place.
The tc-red(8) documentation names two RED qevents:

• early_drop, invoked when packets are early-dropped.
• mark, invoked when RED marks packets in ECN mode. The RED qevent documentation defines both behavior points.

This flexibility is useful. Network operators can mirror traffic, count it, steer it, collect metadata, redirect it, or apply other actions when congestion signals occur. But flexibility also increases the number of ownership and lifecycle transitions kernel code must get right. In CVE-2026-64530, a packet’s handoff to connection-tracking defragmentation was not faithfully represented at the qevent boundary.

The ct action is the other critical component​

The affected scenario also uses the TC connection-tracking action, invoked as action ct. Kernel documentation lists ct as a supported Traffic Control action with attributes for a connection-tracking zone, marks, labels, helpers, NAT information, and related state. The Linux TC netlink specification documents the act-ct configuration interface.
The CVE’s proof-of-concept configuration combines RED’s early_drop qevent with a TC filter that runs action ct. The vulnerable behavior is then reachable with connection-tracking defragmentation enabled and traffic containing out-of-order fragments, such as a fragmented UDP stream. NVD’s technical description supplies that scenario directly.
This combination is specialized, but not implausible. Stateful filtering, virtual switching, service chaining, complex traffic policies, container infrastructure, and software-defined networking can all create environments where Traffic Control and connection tracking coexist. The presence of tc on a system is not enough; the relevant qdisc, qevent, filter block, ct action, and fragmented traffic behavior must converge.

---

The Technical Failure: TC_ACT_CONSUMED Was Not Treated as a Handoff​

The security issue turns on a deceptively simple question: who owns the packet now?
Linux’s networking stack has conventions for TC action results. Kernel documentation for Traffic Control action authors emphasizes that packet ownership matters: actions that queue packets for later processing or redirect them must account for packet handling correctly, and callers are responsible for appropriate cleanup when actions report packet states such as stolen, queued, or dropped. The Linux kernel’s TC action rules describe these ownership expectations in unusually direct language.
In the affected code path, TC_ACT_CONSUMED represents a particularly important condition. The defragmentation engine holds the packet, so the original caller no longer has a valid object to manipulate. Yet tcf_qevent_handle lacked a corresponding switch case and allowed the packet to appear usable to red_enqueue.

The pre-fix behavior​

Conceptually, the vulnerable flow looked like this:

1. RED encountered a packet condition that triggered a configured qevent.
2. RED called into the qevent handler.
3. The qevent handler executed a TC classification path.
4. The ct action encountered an out-of-order fragmented packet and caused the defragmentation engine to retain it.
5. Classification returned TC_ACT_CONSUMED.
6. The qevent handler did not recognize that ownership transition.
7. RED continued operating on a packet pointer that it no longer safely owned.

The impact is a classic use-after-free risk. A packet buffer that has been transferred, reassembled, freed, or reused elsewhere can be touched by stale code. Depending on timing, allocator behavior, hardening features, and what memory is subsequently placed at the reused location, the consequence can range from a crash or networking failure to a more serious compromise of confidentiality, integrity, or availability.
The assigned CVSS vector reflects the potential severity of a successful exploitation chain: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. In plain terms, kernel.org’s CNA assessment characterizes the issue as remotely reachable, low complexity, requiring neither authentication nor user interaction, with high potential impact across confidentiality, integrity, and availability. NVD’s metrics section publishes the kernel.org-provided 9.8 Critical score and vector, while noting that NVD had not yet completed its own scoring assessment.
That score should be interpreted responsibly. The CVSS rating describes worst-case vulnerability characteristics, not universal deployment exposure. A default Linux desktop or ordinary server without RED qevents and ct filters is not in the exact configuration described by the CVE. Conversely, a network appliance or host configured with those capabilities should not dismiss the issue simply because its traffic-control setup is uncommon.

The corrected behavior​

The fix treats TC_ACT_CONSUMED like a stolen packet for purposes of return handling:
That is intentionally restrained. It does not free or drop the packet in the qevent handler, because the handler no longer owns it. Returning NULL tells the caller not to proceed with the SKB. The patch shows the precise implementation.
The distinction between TC_ACT_CONSUMED and ordinary TC_ACT_STOLEN matters. Both indicate that the original caller should stop using the packet, but the CVE description makes explicit that a consumed packet must not be freed at this location because its ownership has moved to the defragmentation engine. NVD stresses that freeing it in the qevent handler would itself be incorrect.

---

Affected Linux Kernel Versions and Patch Availability​

The vulnerability record identifies net/sched/cls_api.c as the affected file and tracks several stable-kernel fix references. The NVD configuration data lists affected version ranges beginning in legacy stable lines including Linux 5.15.148, 6.1.75, and 6.6.14, with respective fixed baselines recorded as 5.15.212, 6.1.178, and 6.6.145. The NVD CVE entry also records the upstream and stable references supplied by kernel.org.
Administrators should avoid interpreting version ranges mechanically when using vendor kernels. Enterprise distributions commonly backport security fixes without changing their kernel to the upstream fixed version. A distribution package might therefore be secure despite appearing numerically older than an upstream version, while a custom-built or self-maintained kernel may need direct patch validation.
Fedora’s package changelog provides a practical example of distribution-level uptake: its Fedora 44 kernel package records the TC_ACT_CONSUMED fix in the 7.1.4-3 changelog entry, dated July 22, 2026. Fedora’s kernel package page shows the backport alongside the upstream Linux 7.1.4 package history.

How to assess an installed system​

The first step is to identify the exact running kernel:
uname -r
Then inspect the distribution’s security advisory, changelog, or source package metadata rather than relying only on upstream version numbers. On RPM-based distributions, that often means reviewing package changelogs and vendor errata. On Debian-family systems, it typically means consulting the security tracker and package changelog for the installed kernel flavor.
For systems that build their own kernels or pull directly from stable trees, the relevant approach is to verify whether the backported commit appears in the source history. The upstream change is identified by commit a8a02897f2b479127db261de05cbf0c28b98d159, authored by Jamal Hadi Salim and committed to the networking tree in June 2026. The upstream commit record also identifies the earlier act_ct fix as the regression point and notes testing by Victor Nogueira.

---

Exposure Assessment: Who Should Treat This as Urgent?​

The practical priority is highest for systems that combine advanced Linux queue management and connection tracking. This includes routers, firewalls, carrier or edge systems, network-function virtualization hosts, high-performance load balancers, and sophisticated virtual networking stacks.

Higher-risk configurations​

Prioritize patching where one or more of the following applies:

• RED qdiscs are actively configured on network interfaces.
• RED uses qevent early_drop or qevent mark.
• A qevent-attached TC block invokes action ct.
• Connection-tracking defragmentation is enabled or reachable.
• The device processes untrusted, externally sourced, or tenant-originated fragmented traffic.
• The system is a multitenant host, gateway, appliance, or security boundary.
• Operators use custom tc scripts, eBPF-adjacent policy workflows, or orchestrator-managed network rules that may hide the final configuration from ordinary interface inspections.

The documented reproduction path uses qevent early_drop, a filter block, action ct, and out-of-order fragmented traffic. NVD provides this configuration outline, while the tc documentation confirms that qevents can attach filter blocks to meaningful queue events. The tc(8) manual

Lower-risk configurations​

Systems are less likely to meet the demonstrated trigger conditions if they:

• Do not use RED at all.
• Use traffic shaping but rely on other qdiscs such as fq_codel, cake, htb, or tbf.
• Use RED but do not attach qevent blocks.
• Use qevents without a ct action capable of retaining fragmented packets.
• Do not accept or process fragmented traffic in the relevant policy path.

“Less likely” is not the same as “not affected.” The kernel bug exists in affected code versions, but exploitability is conditioned by configuration and packet flow. Security operations teams should therefore separate code exposure from reachable attack surface rather than treating the CVSS score as a substitute for environment-specific assessment.

---

Practical Mitigation and Verification Steps​

Patching is the preferred remediation. Configuration changes can reduce exposure when updates are not immediately possible, but they are not a permanent substitute for a corrected kernel.

1. Patch the kernel through the operating-system vendor​

Install the current vendor-supported kernel update and reboot into it. This is especially important for systems that receive distribution-maintained stable kernels rather than upstream builds.
Confirm the active kernel after reboot:
Then compare the installed package release against the vendor’s advisory or changelog. Fedora’s published changelog demonstrates that a distribution can carry this fix as a packaged backport, independent of a simple upstream version comparison. Fedora’s package metadata

2. Inventory RED qdiscs and qevent configuration​

Inspect traffic-control configuration on each relevant network interface:
Look for a RED configuration containing qevent clauses such as:
The RED documentation confirms these as supported qevents, with early_drop tied to early-dropping behavior and mark tied to ECN marking. The tc-red(8) manual

3. Examine attached filter actions​

Where qevents reference blocks, inspect every filter associated with those blocks. The key concern is whether a matching filter invokes action ct, particularly when that action can invoke defragmentation behavior for fragmented flows.
A simplified investigation pattern might include:
The exact command output differs with iproute2 version and policy design, but the goal is straightforward: determine whether an affected qevent block can enter a connection-tracking action path.

4. Apply temporary configuration reductions where patching must wait​

If the environment is demonstrably using the vulnerable combination and a kernel update cannot be deployed immediately, temporary mitigation options include:

• Removing RED qevent attachments.
• Replacing the RED qdisc where operationally acceptable.
• Removing action ct from qevent-linked filter blocks.
• Restricting untrusted fragmented traffic before it reaches the affected host.
• Reducing exposure at external interfaces through upstream firewall, routing, or appliance controls.

These are operationally sensitive actions. Removing a qdisc or filter can affect latency, throughput, fairness, ECN behavior, traffic observability, or stateful policy enforcement. RED is specifically intended to manage congestion behavior, so changes should be evaluated carefully rather than performed blindly. The RED documentation explains the congestion-control consequences of marking and early dropping.

---

Why This Fix Is a Useful Security Lesson​

CVE-2026-64530 illustrates why packet ownership contracts deserve the same security rigor as bounds checking and input validation. Network packets are frequently passed across multiple kernel subsystems: queueing disciplines, classifiers, actions, connection tracking, defragmentation engines, forwarding logic, tunneling code, and device drivers. A one-branch omission at any handoff can turn normal packet processing into memory corruption.
The patch also shows the value of preserving semantic distinctions in kernel return codes. TC_ACT_CONSUMED is not merely another version of “packet handled.” It means the caller no longer owns the SKB. Correctly recognizing that lifecycle transition prevents RED from performing a second operation on the same object.
The Linux kernel’s own TC action guidance captures the broader principle: actions and callers must understand whether a packet is still theirs to free, queue, redirect, or modify. Kernel documentation on TC action rules describes these responsibilities as fundamental environmental rules for Traffic Control code. CVE-2026-64530 is a reminder that security defects often emerge when an exceptional ownership state is omitted from an otherwise familiar control flow.
For organizations with advanced Linux networking, the response should be measured but prompt: identify whether RED qevents and ct actions coexist, install the vendor kernel update that carries the fix, and validate the running kernel rather than assuming a package download alone completed remediation. The vulnerability is specialized, yet it resides in a privileged network-processing path and carries a critical upstream severity assessment. In environments where the required configuration is present, treating the patch as routine maintenance would be an unnecessary risk.

---

References​

1. Primary source: NVD / Linux Kernel
   Published: 2026-07-27T01:04:27-07:00
   
   

   NVD - CVE-2026-64530

   nvd.nist.gov
2. Security advisory: MSRC
   Published: 2026-07-27T01:04:27-07:00
   Original feed URL
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com