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.