### [CVE-2025-21681](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21681)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=066b86787fa3d97b7aefb5ac0a99a22dad2d15f8%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=284be5db6c8d06d247ed056cfc448c4f79bbb16c%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=56252da41426f3d01957456f13caf46ce670ea29%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=5efcb301523baacd98a47553d4996e924923114d%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=6.3%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=644b3051b06ba465bc7401bfae9b14963cbc8c1c%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=9b0dd09c1ceb35950d2884848099fccc9ec9a123%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=blue)

### Description

In the Linux kernel, the following vulnerability has been resolved:openvswitch: fix lockup on tx to unregistering netdev with carrierCommit in a fixes tag attempted to fix the issue in the followingsequence of calls:    do_output    -> ovs_vport_send       -> dev_queue_xmit          -> __dev_queue_xmit             -> netdev_core_pick_tx                -> skb_tx_hashWhen device is unregistering, the 'dev->real_num_tx_queues' goes tozero and the 'while (unlikely(hash >= qcount))' loop inside the'skb_tx_hash' becomes infinite, locking up the core forever.But unfortunately, checking just the carrier status is not enough tofix the issue, because some devices may still be in unregisteringstate while reporting carrier status OK.One example of such device is a net/dummy.  It sets carrier ONon 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 hitthe infinite loop in the skb_tx_hash() from the OVS datapath.  Theremight be other drivers that do the same, but dummy by itself isimportant for the OVS ecosystem, because it is frequently used as apacket sink for tcpdump while debugging OVS deployments.  And when theissue is hit, the only way to recover is to reboot.Fix that by also checking if the device is running.  The runningstate is handled by the net core during unregistering, so it coversunregistering case better, and we don't really need to send packetsto devices that are not running anyway.While only checking the running state might be enough, the carriercheck is preserved.  The running and the carrier states seem disjoinedthroughout the code and different drivers.  And other core functionslike __dev_direct_xmit() check both before attempting to transmita packet.  So, it seems safer to check both flags in OVS as well.

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/fkie-cad/nvd-json-data-feeds
- https://github.com/w4zu/Debian_security