linux-cve-announce - CVE-2025-21681: openvswitch: fix lockup on tx to unregistering netdev with carrier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025013103-CVE-2025-21681-ed9d@gregkh>
Date: Fri, 31 Jan 2025 12:31:13 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2025-21681: openvswitch: fix lockup on tx to unregistering netdev with carrier

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

openvswitch: fix lockup on tx to unregistering netdev with carrier

Commit in a fixes tag attempted to fix the issue in the following
sequence of calls:

    do_output
    -> ovs_vport_send
       -> dev_queue_xmit
          -> __dev_queue_xmit
             -> netdev_core_pick_tx
                -> skb_tx_hash

When device is unregistering, the 'dev->real_num_tx_queues' goes to
zero 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 to
fix the issue, because some devices may still be in unregistering
state while reporting carrier status OK.

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.

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 better, and we don't really need to send packets
to devices that are not running anyway.

While only checking the running state might be enough, the carrier
check is preserved.  The running and the carrier states seem disjoined
throughout the code and different drivers.  And other core functions
like __dev_direct_xmit() check both before attempting to transmit
a packet.  So, it seems safer to check both flags in OVS as well.

The Linux kernel CVE team has assigned CVE-2025-21681 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 6.1.25 with commit 644b3051b06ba465bc7401bfae9b14963cbc8c1c and fixed in 6.1.127 with commit ea9e990356b7bee95440ba0e6e83cc4d701afaca
	Issue introduced in 6.3 with commit 066b86787fa3d97b7aefb5ac0a99a22dad2d15f8 and fixed in 6.6.74 with commit ea966b6698785fb9cd0fdb867acd91b222e4723f
	Issue introduced in 6.3 with commit 066b86787fa3d97b7aefb5ac0a99a22dad2d15f8 and fixed in 6.12.11 with commit 82f433e8dd0629e16681edf6039d094b5518d8ed
	Issue introduced in 6.3 with commit 066b86787fa3d97b7aefb5ac0a99a22dad2d15f8 and fixed in 6.13 with commit 47e55e4b410f7d552e43011baa5be1aab4093990
	Issue introduced in 6.2.12 with commit 56252da41426f3d01957456f13caf46ce670ea29

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-21681
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	net/openvswitch/actions.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/ea9e990356b7bee95440ba0e6e83cc4d701afaca
	https://git.kernel.org/stable/c/ea966b6698785fb9cd0fdb867acd91b222e4723f
	https://git.kernel.org/stable/c/82f433e8dd0629e16681edf6039d094b5518d8ed
	https://git.kernel.org/stable/c/47e55e4b410f7d552e43011baa5be1aab4093990