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
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
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update 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 13trixie | fixedDSA-6466-1 · 2026-08-25 · text | 6.12.105-1 | Update 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 14forky | fixed | 7.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.9-1 | Update 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.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update 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_ctPrints 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
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.15.148 | 5.15.217 | b5dbecc2016e |
| 6.1.75 | 6.1.184 | 23e97d594ddd |
| 6.6.14 | 6.6.152 | 737873a59905 |
| 6.8 | 6.12.104 | 47d99828591d |
| 6.8 | 6.18.45 | b47bb899e04b |
| 6.8 | 7.1.9 | 439d3e404f9d |
| 6.8 | 7.2 | 8a7ed561671a |
| 6.7.2 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DSA-6466-1 | 2026-08-25 | trixie 6.12.105-1 | tracker |
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).