CVE-2026-74621: net/sched: act_ct: fix sk_buff leak when the header checks reject a packet
Greg Kroah-Hartman <[email protected]>
| Newsgroups | org.kernel.vger.linux-cve-announce |
|---|---|
| Message-ID | <2026082219-CVE-2026-74621-81bd@gregkh> |
From: Greg Kroah-Hartman <[email protected]> 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