CVE-2026-74621

High

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.

Package Linux Kernel
Published 2026-08-22
Last modified 2026-08-25
CVSS version 3.1
Patch available
Yes

CVSS 3.1 score

7.5

out of 10
High
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
High
Vector string
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Affected versions

Linux kernel versions 5.15.148, 6.1.75, 6.6.14, 6.7.2, 6.8 and later are affected. Fixed in 5.15.217, 6.1.184, 6.6.152, 6.12.104, 6.18.45, 7.1.9, 7.2 and their respective stable series.

Affected from
≥ 5.15.148 ≥ 6.1.75 ≥ 6.6.14 ≥ 6.7.2 ≥ 6.8
Fixed in
✓ 5.15.217 5.15.x ✓ 6.1.184 6.1.x ✓ 6.6.152 6.6.x ✓ 6.12.104 6.12.x ✓ 6.18.45 6.18.x ✓ 7.1.9 7.1.x ✓ 7.2

Frequently asked questions

  • What is CVE-2026-74621?

    CVE-2026-74621 is a High severity Linux kernel vulnerability with a CVSS score of 7.5 out of 10 . It affects Linux kernel versions from 5.15.148 onward and has been patched in 5.15.217, 6.1.184, 6.6.152 and others. CVE-2026-74621 has not been confirmed as actively exploited and is not listed in the CISA KEV catalog.

  • What is the CVSS score for CVE-2026-74621?

    CVE-2026-74621 has a CVSS score of 7.5 out of 10, rated High severity (CVSS 3.1). The vector string is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H .

  • Is there a patch available for CVE-2026-74621?

    Yes. CVE-2026-74621 has been patched. Fixed versions include 5.15.217, 6.1.184, 6.6.152 and others. If you are running Linux kernel 5.15.148 or later up to the fix versions, apply the relevant patch for your kernel branch.

  • Is CVE-2026-74621 actively exploited?

    No. CVE-2026-74621 has not been confirmed as actively exploited. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.