<?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://cve.radiocsirt.org</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 18:18:01 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-21681 — openvswitch: fix lockup on tx to unregistering netdev with carrier</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-21681</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;openvswitch: fix lockup on tx to unregistering netdev with carrier&lt;/p&gt;
&lt;p&gt;Commit in a fixes tag attempted to fix the issue in the following
sequence of calls:&lt;/p&gt;
&lt;p&gt;do_output
    -&amp;gt; ovs_vport_send
       -&amp;gt; dev_queue_xmit
          -&amp;gt; __dev_queue_xmit
             -&amp;gt; netdev_core_pick_tx
                -&amp;gt; skb_tx_hash&lt;/p&gt;
&lt;p&gt;When device is unregistering, the &amp;#39;dev-&amp;gt;real_num_tx_queues&amp;#39; goes to
zero and the &amp;#39;while (unlikely(hash &amp;gt;= qcount))&amp;#39; loop inside the
&amp;#39;skb_tx_hash&amp;#39; becomes infinite, locking up the core forever.&lt;/p&gt;
&lt;p&gt;But unfortunately, checking just the carrier status is not enough to
fix the issue, because some devices may still be in unregistering
state while reporting carrier status OK.&lt;/p&gt;
&lt;p&gt;One example of such device is a net/dummy.  It sets carrier ON
on start, but it doesn&amp;#39;t implement .ndo_stop to set the carrier off.
And it makes sense, because dummy doesn&amp;#39;t really have a carrier.
Therefore, while this device is unregistering, it&amp;#39;s still easy to hit
the infinite loop in the skb_tx_hash() from the OVS datapath.  There
might be other drivers that do the same, but dummy by itself is
important for the OVS ecosystem, because it is frequently used as a
packet sink for tcpdump while debugging OVS deployments.  And when the
issue is hit, the only way to recover is to reboot.&lt;/p&gt;
&lt;p&gt;Fix that by also checking if the device is running.  The running
state is handled by the net core during unregistering, so it covers
unregistering case be…&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;openvswitch: fix lockup on tx to unregistering netdev with carrier&lt;/p&gt;
&lt;p&gt;Commit in a fixes tag attempted to fix the issue in the following
sequence of calls:&lt;/p&gt;
&lt;p&gt;do_output
    -&amp;gt; ovs_vport_send
       -&amp;gt; dev_queue_xmit
          -&amp;gt; __dev_queue_xmit
             -&amp;gt; netdev_core_pick_tx
                -&amp;gt; skb_tx_hash&lt;/p&gt;
&lt;p&gt;When device is unregistering, the &amp;#39;dev-&amp;gt;real_num_tx_queues&amp;#39; goes to
zero and the &amp;#39;while (unlikely(hash &amp;gt;= qcount))&amp;#39; loop inside the
&amp;#39;skb_tx_hash&amp;#39; becomes infinite, locking up the core forever.&lt;/p&gt;
&lt;p&gt;But unfortunately, checking just the carrier status is not enough to
fix the issue, because some devices may still be in unregistering
state while reporting carrier status OK.&lt;/p&gt;
&lt;p&gt;One example of such device is a net/dummy.  It sets carrier ON
on start, but it doesn&amp;#39;t implement .ndo_stop to set the carrier off.
And it makes sense, because dummy doesn&amp;#39;t really have a carrier.
Therefore, while this device is unregistering, it&amp;#39;s still easy to hit
the infinite loop in the skb_tx_hash() from the OVS datapath.  There
might be other drivers that do the same, but dummy by itself is
important for the OVS ecosystem, because it is frequently used as a
packet sink for tcpdump while debugging OVS deployments.  And when the
issue is hit, the only way to recover is to reboot.&lt;/p&gt;
&lt;p&gt;Fix that by also checking if the device is running.  The running
state is handled by the net core during unregistering, so it covers
unregistering case be…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-21681</guid>
    </item>
  </channel>
</rss>
