CVE-2025-21681

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openvswitch: fix lockup on tx to unregistering netdev with carrier<br /> <br /> Commit in a fixes tag attempted to fix the issue in the following<br /> sequence of calls:<br /> <br /> do_output<br /> -&gt; ovs_vport_send<br /> -&gt; dev_queue_xmit<br /> -&gt; __dev_queue_xmit<br /> -&gt; netdev_core_pick_tx<br /> -&gt; skb_tx_hash<br /> <br /> When device is unregistering, the &amp;#39;dev-&gt;real_num_tx_queues&amp;#39; goes to<br /> zero and the &amp;#39;while (unlikely(hash &gt;= qcount))&amp;#39; loop inside the<br /> &amp;#39;skb_tx_hash&amp;#39; becomes infinite, locking up the core forever.<br /> <br /> But unfortunately, checking just the carrier status is not enough to<br /> fix the issue, because some devices may still be in unregistering<br /> state while reporting carrier status OK.<br /> <br /> One example of such device is a net/dummy. It sets carrier ON<br /> on start, but it doesn&amp;#39;t implement .ndo_stop to set the carrier off.<br /> And it makes sense, because dummy doesn&amp;#39;t really have a carrier.<br /> Therefore, while this device is unregistering, it&amp;#39;s still easy to hit<br /> the infinite loop in the skb_tx_hash() from the OVS datapath. There<br /> might be other drivers that do the same, but dummy by itself is<br /> important for the OVS ecosystem, because it is frequently used as a<br /> packet sink for tcpdump while debugging OVS deployments. And when the<br /> issue is hit, the only way to recover is to reboot.<br /> <br /> Fix that by also checking if the device is running. The running<br /> state is handled by the net core during unregistering, so it covers<br /> unregistering case better, and we don&amp;#39;t really need to send packets<br /> to devices that are not running anyway.<br /> <br /> While only checking the running state might be enough, the carrier<br /> check is preserved. The running and the carrier states seem disjoined<br /> throughout the code and different drivers. And other core functions<br /> like __dev_direct_xmit() check both before attempting to transmit<br /> a packet. So, it seems safer to check both flags in OVS as well.