CVE-2026-64530
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceA Use-After-Free vulnerability exists in the Linux kernel's net/sched/cls_api where tcf_qevent_handle() fails to handle TC_ACT_CONSUMED properly. When tcf_classify() returns TC_ACT_CONSUMED (e.g., when the skb is held by the defragmentation engine for out-of-order fragments), the function incorrectly returns the skb to the caller. The RED qdisc then continues operating on an skb it no longer owns—enqueueing, dropping, or updating statistics—resulting in a UAF.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Check kernel versionRun `uname -r` to retrieve the running kernel version. Compare this against the version that includes the fix for CVE-2026-64530 in tcf_qevent_handle().Affected if Kernel version is older than the patched version and has the vulnerable code path in net/sched/cls_api.c
-
Confirm conntrack defragmentation is enabledCheck if conntrack defrag is active by running `sysctl net.netfilter.nf_conntrack_defrag_help` or by inspecting active tc rules for the 'ct defrag' action using `tc filter show`.Affected if Conntrack defragmentation (ct defrag) is enabled - this is required for the vulnerability to be exploitable
-
Identify RED qdisc with qevent blocksRun `tc qdisc show` to list all qdisc configurations. Look for RED qdiscs that include 'qevent' blocks, for example output containing 'qevent' or 'red' in the tc qdisc output.Affected if RED qdisc is configured with qevent blocks - this specific combination triggers the vulnerable tcf_qevent_handle() code path
-
Verify qevent filter action chainRun `tc filter show` to inspect filter rules. Check if any filters with qevent actions are attached to the RED qdisc identified in the previous step.Affected if Filters using qevent blocks are actively attached to a RED qdisc, enabling the vulnerable code path where TC_ACT_CONSUMED is mishandled
Environment is affected if running a vulnerable kernel version with conntrack defrag enabled AND using RED qdisc with qevent blocks, which causes tcf_qevent_handle() to return an unowned skb instead of treating it as stolen.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedApply the upstream Linux kernel patch that adds proper handling of TC_ACT_CONSUMED in tcf_qevent_handle(), then update the kernel on affected systems. This is a kernel-level fix requiring system reboot.
- Obtain the Linux kernel source code, specifically net/sched/cls_api.c
- Locate the tcf_qevent_handle() function
- Add a case for TC_ACT_CONSUMED in the switch statement that handles tcf_classify() return values
- The TC_ACT_CONSUMED case should return NULL without touching the skb (unlike TC_ACT_STOLEN which would free/drop the skb)
- Recompile the kernel with the patched cls_api.c
- Deploy the updated kernel to affected systems
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation2.0 h
- Implementation2.0 h
- Testing4.0 h
- Review / QA2.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,752.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-64530 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-64530 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data