<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-08T22:40:07.756771+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2025-21681</id>
    <title>CVE-2025-21681 — openvswitch: fix lockup on tx to unregistering netdev with carrier</title>
    <updated>2026-10-08T22:40:07.776533+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>openvswitch: fix lockup on tx to unregistering netdev with carrier</p>
<p>Commit in a fixes tag attempted to fix the issue in the following
sequence of calls:</p>
<p>do_output
    -&gt; ovs_vport_send
       -&gt; dev_queue_xmit
          -&gt; __dev_queue_xmit
             -&gt; netdev_core_pick_tx
                -&gt; skb_tx_hash</p>
<p>When device is unregistering, the 'dev-&gt;real_num_tx_queues' goes to
zero and the 'while (unlikely(hash &gt;= qcount))' loop inside the
'skb_tx_hash' becomes infinite, locking up the core forever.</p>
<p>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.</p>
<p>One example of such device is a net/dummy.  It sets carrier ON
on start, but it doesn't implement .ndo_stop to set the carrier off.
And it makes sense, because dummy doesn't really have a carrier.
Therefore, while this device is unregistering, it'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.</p>
<p>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…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2025-21681"/>
  </entry>
</feed>
