CVE-2026-74621: net/sched: act_ct: fix sk_buff leak when the header checks reject a packet

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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.

The Linux kernel CVE team has assigned CVE-2026-74621 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.6.14 with commit 73f7da5fd124f2cda9161e2e46114915e6e82e97 and fixed in 6.6.152 with commit 737873a59905a54ca0d2d127ef882f3f88bf4379
	Issue introduced in 6.8 with commit 3f14b377d01d8357eba032b4cabc8c1149b458b6 and fixed in 6.12.104 with commit 47d99828591d0fe8be4b9c8992ff3b8e47968db9
	Issue introduced in 6.8 with commit 3f14b377d01d8357eba032b4cabc8c1149b458b6 and fixed in 6.18.45 with commit b47bb899e04b5407c5a63fe88d4b6676586a6e84
	Issue introduced in 6.8 with commit 3f14b377d01d8357eba032b4cabc8c1149b458b6 and fixed in 7.1.9 with commit 439d3e404f9d5e515911cc8132cde198b337c19e
	Issue introduced in 6.8 with commit 3f14b377d01d8357eba032b4cabc8c1149b458b6 and fixed in 7.2 with commit 8a7ed561671aa6a911a2de99e59ef670a4d0b1df
	Issue introduced in 5.15.148 with commit 172ba7d46c202e679f3ccb10264c67416aaeb1c4
	Issue introduced in 6.1.75 with commit 0b5b831122fc3789fff75be433ba3e4dd7b779d4
	Issue introduced in 6.7.2 with commit f5346df0591d10bc948761ca854b1fae6d2ef441

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-74621
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/sched/act_ct.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/737873a59905a54ca0d2d127ef882f3f88bf4379
	https://git.kernel.org/stable/c/47d99828591d0fe8be4b9c8992ff3b8e47968db9
	https://git.kernel.org/stable/c/b47bb899e04b5407c5a63fe88d4b6676586a6e84
	https://git.kernel.org/stable/c/439d3e404f9d5e515911cc8132cde198b337c19e
	https://git.kernel.org/stable/c/8a7ed561671aa6a911a2de99e59ef670a4d0b1df