CVE-2026-74621: net/sched: act_ct: fix sk_buff leak when the header checks reject a packet
In the Linux kernel, the following vulnerability has been resolved:
net/sched: actct: fix skbuff leak when the header checks reject a packet
tcfcthandlefragments() runs its header sanity checks before handing anything to the defragmentation engine:
if (family == NFPROTOIPV4) err = tcfctipv4isfragment(skb, &frag); else err = tcfctipv6isfragment(skb, &frag); if (err || !frag) return err;
tcfctipv4isfragment() returns -EINVAL or -ENOMEM; tcfctipv6isfragment() adds -EPROTO when ipv6findhdr() fails. None of them frees or queues the skb, so on that path the caller still owns it.
tcfctact() however funnels every non-zero return into the ownership-transfer exit:
err = tcfcthandlefragments(net, skb, family, p->zone, &defrag); if (err) goto outfrag; ... outfrag: if (err != -EINPROGRESS) tcfactionincdropqstats(&c->common); return TCACTCONSUMED;
TCACTCONSUMED means the action took ownership of the skb, so no caller frees it - schhandleingress(), schhandleegress() and tcfqeventhandle() all deliberately skip the free for that verdict. The skb is therefore orphaned: one skbuff 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 outfrag: today - the skb may be queued by the defrag engine (-EINPROGRESS), already freed by nfcthandlefragments(), 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 TCACTSHOT 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 skbuffheadcache object plus its 704-byte data buffer per packet; with this patch it reports none.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems are exposed when traffic reaches the tc act_ct action and malformed IPv4 or IPv6 packets trigger its header sanity-check failure paths. The affected paths include IPv4 checks returning -EINVAL or -ENOMEM and IPv6 header parsing failures returning -EPROTO.
What does an attacker need to do to trigger the leak?
An attacker needs to send malformed packets that cause the act_ct fragment/header checks to fail before the packet is passed to the defragmentation engine. Each such rejected packet can orphan one sk_buff and its associated data buffer.
What is the operational impact of repeated exploitation?
The leak is unbounded because the packet is treated as consumed even though no component frees or queues it. Repeated malformed packets can therefore continually consume kernel memory.
Is there an observable signal when the vulnerable path is hit?
The action increments its drop queue statistics for these errors, except when the error is -EINPROGRESS. Increased act_ct drop statistics alongside memory growth may indicate that malformed-packet rejection paths are being exercised.