CVE-2025-21681
Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
31/01/2025
Last modified:
02/05/2025
Description
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 />
-> ovs_vport_send<br />
-> dev_queue_xmit<br />
-> __dev_queue_xmit<br />
-> netdev_core_pick_tx<br />
-> skb_tx_hash<br />
<br />
When device is unregistering, the &#39;dev->real_num_tx_queues&#39; goes to<br />
zero and the &#39;while (unlikely(hash >= qcount))&#39; loop inside the<br />
&#39;skb_tx_hash&#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&#39;t implement .ndo_stop to set the carrier off.<br />
And it makes sense, because dummy doesn&#39;t really have a carrier.<br />
Therefore, while this device is unregistering, it&#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&#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.
Impact
Base Score 3.x
5.50
Severity 3.x
MEDIUM
Vulnerable products and versions
CPE | From | Up to |
---|---|---|
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 6.1.25 (including) | 6.1.127 (excluding) |
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 6.2.12 (including) | 6.6.74 (excluding) |
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 6.7 (including) | 6.12.11 (excluding) |
cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.13:rc2:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.13:rc3:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.13:rc4:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.13:rc5:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.13:rc6:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.13:rc7:*:*:*:*:*:* |
To consult the complete list of CPE names with products and versions, see this page
References to Advisories, Solutions, and Tools
- https://git.kernel.org/stable/c/47e55e4b410f7d552e43011baa5be1aab4093990
- https://git.kernel.org/stable/c/82f433e8dd0629e16681edf6039d094b5518d8ed
- https://git.kernel.org/stable/c/87fcf0d137c770e6040ebfdb0abd8e7dd481b504
- https://git.kernel.org/stable/c/930268823f6bccb697aa5d2047aeffd4a497308c
- https://git.kernel.org/stable/c/b5c73fc92f8d15c16e5dc87b5c17d2abf1e6d092
- https://git.kernel.org/stable/c/ea966b6698785fb9cd0fdb867acd91b222e4723f
- https://git.kernel.org/stable/c/ea9e990356b7bee95440ba0e6e83cc4d701afaca