CVE-2026-74621

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_ct: fix sk_buff leak when the header checks reject a packet<br /> <br /> tcf_ct_handle_fragments() runs its header sanity checks before handing<br /> anything to the defragmentation engine:<br /> <br /> if (family == NFPROTO_IPV4)<br /> err = tcf_ct_ipv4_is_fragment(skb, &amp;frag);<br /> else<br /> err = tcf_ct_ipv6_is_fragment(skb, &amp;frag);<br /> if (err || !frag)<br /> return err;<br /> <br /> tcf_ct_ipv4_is_fragment() returns -EINVAL or -ENOMEM;<br /> tcf_ct_ipv6_is_fragment() adds -EPROTO when ipv6_find_hdr() fails. None of<br /> them frees or queues the skb, so on that path the caller still owns it.<br /> <br /> tcf_ct_act() however funnels every non-zero return into the<br /> ownership-transfer exit:<br /> <br /> err = tcf_ct_handle_fragments(net, skb, family, p-&gt;zone, &amp;defrag);<br /> if (err)<br /> goto out_frag;<br /> ...<br /> out_frag:<br /> if (err != -EINPROGRESS)<br /> tcf_action_inc_drop_qstats(&amp;c-&gt;common);<br /> return TC_ACT_CONSUMED;<br /> <br /> TC_ACT_CONSUMED means the action took ownership of the skb, so no caller<br /> frees it - sch_handle_ingress(), sch_handle_egress() and<br /> tcf_qevent_handle() all deliberately skip the free for that verdict. The<br /> skb is therefore orphaned: one sk_buff plus its data buffer is leaked per<br /> malformed packet, unbounded. Note the drop counter is already incremented<br /> for these errors, so the statistics claim a drop that never happens.<br /> <br /> Three different ownership states reach out_frag: today - the skb may be<br /> queued by the defrag engine (-EINPROGRESS), already freed by<br /> nf_ct_handle_fragments(), or still owned by us. Tell the caller which of<br /> those it is, and free the packet ourselves in the last case, which<br /> restores the TC_ACT_SHOT behaviour that predated the Fixes: commit.<br /> <br /> Reproduced on v7.2-rc6 with a 54-byte frame carrying a 40-byte IPv6<br /> header with nexthdr = 0 (hop-by-hop) and nothing after it, on a<br /> clsact ingress chain with "action ct". kmemleak reports one leaked<br /> 232-byte skbuff_head_cache object plus its 704-byte data buffer per<br /> packet; with this patch it reports none.