data built 2026-10-19T13:16:53Z

Look up another CVE · open CVE-2026-74621 in the interactive tracker

CVE-2026-74621

net/sched: act_ct: fix sk_buff leak when the header checks reject a packet

7.5 EPSS 0.5% AV:N

Published 2026-08-22 (2 months ago) by the Linux kernel CNA. Subsystem net/sched. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-74621 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

ReleaseStatus VersionWhat this means
Debian 12bookwormfixedDLA-4777-1 · 2026-09-08 · text6.1.187-1Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixiefixedDSA-6466-1 · 2026-08-25 · text6.12.105-1Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed7.1.9-1Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed7.1.9-1Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12fixedDLA-4788-1 · 2026-09-19 · text6.12.107-1~deb12u1Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

tcf_ct_handle_fragments() runs its header sanity checks before handing anything to the defragmentation engine: if (family == NFPROTO_IPV4) err = tcf_ct_ipv4_is_fragment(skb, &frag); else err = tcf_ct_ipv6_is_fragment(skb, &frag); if (err || !frag) return err; tcf_ct_ipv4_is_fragment() returns -EINVAL or -ENOMEM; tcf_ct_ipv6_is_fragment() adds -EPROTO when ipv6_find_hdr() fails. None of them frees or queues the skb, so on that path the caller still owns it. tcf_ct_act() however funnels every non-zero return into the ownership-transfer exit: err = tcf_ct_handle_fragments(net, skb, family, p->zone, &defrag); if (err) goto out_frag; ... out_frag: if (err != -EINPROGRESS) tcf_action_inc_drop_qstats(&c->common); return TC_ACT_CONSUMED; TC_ACT_CONSUMED means the action took ownership of the skb, so no caller frees it - sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for that verdict. The skb is therefore orphaned: one sk_buff plus its data buffer is leaked per malformed packet, unbounded. Note the drop counter is already incremented for these errors, so the statistics claim a drop that never happens. Three different ownership states reach out_frag: today - the skb may be queued by the defrag engine (-EINPROGRESS), already freed by nf_ct_handle_fragments(), or still owned by us. Tell the caller which of those it is, and free the packet ourselves in the last case, which restores the TC_ACT_SHOT behaviour that predated the Fixes: commit. Reproduced on v7.2-rc6 with a 54-byte frame carrying a 40-byte IPv6 header with nexthdr = 0 (hop-by-hop) and nothing after it, on a clsact ingress chain with "action ct". kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet; with this patch it reports none.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

net/sched/act_ct.c

What this is
TC subsystemMAINTAINERS section matched on net/sched/ · netdev@vger.kernel.org · Maintained
Kernel module
act_ct

Check it on the machine

grep -w CONFIG_NET_ACT_CT /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w act_ct

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

  • bookworm, trixie, forky, sid, bookworm · linux-6.12m
m
a loadable module on every flavour - check lsmod, can be blacklisted
Build switch
CONFIG_NET_ACT_CT

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published
2026-08-22 (2 months ago)source
CVSS
7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it
Attack vector
network (AV:N)source
EPSS
0.49%, higher than 40.8% of all CVEssource
CISA KEV
not listedthe KEV catalogue
Debian urgency
not yet assignedsource
Subsystem
net/sched

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

IntroducedFixed inCommit
5.15.1485.15.217b5dbecc2016e
6.1.756.1.18423e97d594ddd
6.6.146.6.152737873a59905
6.86.12.10447d99828591d
6.86.18.45b47bb899e04b
6.87.1.9439d3e404f9d
6.87.28a7ed561671a
6.7.200

Debian advisories

AdvisoryDateShipped toDebian
DLA-4788-12026-09-19bookworm 6.12.107-1~deb12u1tracker
DLA-4777-12026-09-08bookworm 6.1.187-1tracker
DSA-6466-12026-08-25trixie 6.12.105-1tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network
The leak is triggered in tcf_ct_act() on the packet datapath (netif_receive_skb → sch_handle_ingress/egress → tc_run → tcf_classify); on OVN/Kubernetes/SDN gateways and mlx5-offload nodes with act_ct on clsact, a remote peer sends malformed IP packets with no local access required.
AC:LAttack complexity, low
The attacker fully controls packet contents; a 54-byte IPv6 frame with nexthdr=0 (hop-by-hop) and no trailing data deterministically makes ipv6_find_hdr() return -EPROTO, leaking one skb per packet without races or uncontrollable layout dependencies.
PR:NPrivileges required, none
Installing act_ct requires CAP_NET_ADMIN, but triggering the leak on an already-configured internet-facing or tenant-facing gateway needs no target credentials; a remote attacker only sends crafted malformed IP packets, matching CNA precedent for packet-driven act_ct issues (e.g., CVE-2026-72057).
UI:NUser interaction, none
Exploitation requires only attacker-generated malformed packets reaching a host with act_ct on clsact/ingress or egress; no victim login, mount, or other interactive action is needed beyond normal network traffic processing.
S:UScope, unchanged
The leaked sk_buff objects remain within the host kernel memory domain; this is not a VM escape, sandbox breakout, or IOMMU boundary bypass, only unbounded kernel heap consumption on the affected node.
C:NConfidentiality impact, none
This is a pure sk_buff ownership leak on an error path; skb memory is orphaned, not exposed to the attacker, with no out-of-bounds read, use-after-free, or other disclosure primitive.
I:NIntegrity impact, none
The flaw only fails to kfree_skb() when header validation rejects a packet; it does not corrupt, overwrite, or modify any memory contents and provides no write or code-execution primitive.
A:HAvailability impact, high
Each malformed packet leaks one sk_buff plus its data buffer (~936 bytes); sustained remote flooding causes unbounded kernel memory exhaustion and OOM denial of service, matching CNA precedent for repeatable network-triggered skb leaks (e.g., CVE-2026-52974).