<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 08 Oct 2026 13:42:41 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-26921 — inet: inet_defrag: prevent sk release while still in use</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-26921</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;inet: inet_defrag: prevent sk release while still in use&lt;/p&gt;
&lt;p&gt;ip_local_out() and other functions can pass skb-&amp;gt;sk as function argument.&lt;/p&gt;
&lt;p&gt;If the skb is a fragment and reassembly happens before such function call
returns, the sk must not be released.&lt;/p&gt;
&lt;p&gt;This affects skb fragments reassembled via netfilter or similar
modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.&lt;/p&gt;
&lt;p&gt;Eric Dumazet made an initial analysis of this bug.  Quoting Eric:
  Calling ip_defrag() in output path is also implying skb_orphan(),
  which is buggy because output path relies on sk not disappearing.&lt;/p&gt;
&lt;p&gt;A relevant old patch about the issue was :
  8282f27449bf (&amp;#34;inet: frag: Always orphan skbs inside ip_defrag()&amp;#34;)&lt;/p&gt;
&lt;p&gt;[..]&lt;/p&gt;
&lt;p&gt;net/ipv4/ip_output.c depends on skb-&amp;gt;sk being set, and probably to an
  inet socket, not an arbitrary one.&lt;/p&gt;
&lt;p&gt;If we orphan the packet in ipvlan, then downstream things like FQ
  packet scheduler will not work properly.&lt;/p&gt;
&lt;p&gt;We need to change ip_defrag() to only use skb_orphan() when really
  needed, ie whenever frag_list is going to be used.&lt;/p&gt;
&lt;p&gt;Eric suggested to stash sk in fragment queue and made an initial patch.
However there is a problem with this:&lt;/p&gt;
&lt;p&gt;If skb is refragmented again right after, ip_do_fragment() will copy
head-&amp;gt;sk to the new fragments, and sets up destructor to sock_wfree.
IOW, we have no choice but to fix up sk_wmem accouting to reflect the
fully reassembled skb, else wmem will underflow.&lt;/p&gt;
&lt;p&gt;This ch…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;inet: inet_defrag: prevent sk release while still in use&lt;/p&gt;
&lt;p&gt;ip_local_out() and other functions can pass skb-&amp;gt;sk as function argument.&lt;/p&gt;
&lt;p&gt;If the skb is a fragment and reassembly happens before such function call
returns, the sk must not be released.&lt;/p&gt;
&lt;p&gt;This affects skb fragments reassembled via netfilter or similar
modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.&lt;/p&gt;
&lt;p&gt;Eric Dumazet made an initial analysis of this bug.  Quoting Eric:
  Calling ip_defrag() in output path is also implying skb_orphan(),
  which is buggy because output path relies on sk not disappearing.&lt;/p&gt;
&lt;p&gt;A relevant old patch about the issue was :
  8282f27449bf (&amp;#34;inet: frag: Always orphan skbs inside ip_defrag()&amp;#34;)&lt;/p&gt;
&lt;p&gt;[..]&lt;/p&gt;
&lt;p&gt;net/ipv4/ip_output.c depends on skb-&amp;gt;sk being set, and probably to an
  inet socket, not an arbitrary one.&lt;/p&gt;
&lt;p&gt;If we orphan the packet in ipvlan, then downstream things like FQ
  packet scheduler will not work properly.&lt;/p&gt;
&lt;p&gt;We need to change ip_defrag() to only use skb_orphan() when really
  needed, ie whenever frag_list is going to be used.&lt;/p&gt;
&lt;p&gt;Eric suggested to stash sk in fragment queue and made an initial patch.
However there is a problem with this:&lt;/p&gt;
&lt;p&gt;If skb is refragmented again right after, ip_do_fragment() will copy
head-&amp;gt;sk to the new fragments, and sets up destructor to sock_wfree.
IOW, we have no choice but to fix up sk_wmem accouting to reflect the
fully reassembled skb, else wmem will underflow.&lt;/p&gt;
&lt;p&gt;This ch…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-26921</guid>
    </item>
  </channel>
</rss>
