CVE-2026-74621

Status: UPDATED  |  Advisory ID: CVE-2026-74621

Key Details

Affected Products, Subsystems & Sectors

What to Know

In the Linux kernel, the following vulnerability has been resolved:

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

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References