CVE-2025-21681: Software Security Vulnerability Vulnerability
MODERATECVE-2025-21681 is a MODERATE (CVSS 5.5) security vulnerability vulnerability (CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')) affecting Software libraries in the Maven ecosystem. The weakness occurs when the product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.. Remediation is available in the latest vendor maintenance releases.
CVE-2025-21681 at a Glance
Security Impact
CVSS: 5.5
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).
How to Fix CVE-2025-21681
To remediate this vulnerability, upgrade all affected Software dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
mvn dependency:treeHow to Check if You Are Affected
To determine whether your Java application is affected by CVE-2025-21681, inspect your build dependencies using the Maven Dependency Plugin:
mvn dependency:treeAnalyze the terminal output to locate any version of Software in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.
Note: The mvn dependency:tree command inspects the resolved dependency graph declared in your project's POM files; it does not perform automated security scanning or inspect runtime dynamic classpaths. Always verify runtime container classpaths and shaded JARs.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop'), where the product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop. In Software, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
References
Frequently Asked Questions
What is CVE-2025-21681?
Which Software versions are affected?
What version fixes CVE-2025-21681?
What is the CVSS score of CVE-2025-21681?
What CWE is associated with CVE-2025-21681?
How can I check Maven dependencies for CVE-2025-21681?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-2x4f-r6q9-v77h",
"modified" : "2025-11-03T21:32:30Z",
"published" : "2025-01-31T12:33:03Z",
"aliases" : [ "CVE-2025-21681" ],
"details" : "In the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: fix lockup on tx to unregistering netdev with carrier\n\nCommit in a fixes tag attempted to fix the issue in the following\nsequence of calls:\n\n do_output\n -> ovs_vport_send\n -> dev_queue_xmit\n -> __dev_queue_xmit\n -> netdev_core_pick_tx\n -> skb_tx_hash\n\nWhen device is unregistering, the 'dev->real_num_tx_queues' goes to\nzero and the 'while (unlikely(hash >= qcount))' loop inside the\n'skb_tx_hash' becomes infinite, locking up the core forever.\n\nBut unfortunately, checking just the carrier status is not enough to\nfix the issue, because some devices may still be in unregistering\nstate while reporting carrier status OK.\n\nOne example of such device is a net/dummy. It sets carrier ON\non start, but it doesn't implement .ndo_stop to set the carrier off.\nAnd it makes sense, because dummy doesn't really have a carrier.\nTherefore, while this device is unregistering, it's still easy to hit\nthe infinite loop in the skb_tx_hash() from the OVS datapath. There\nmight be other drivers that do the same, but dummy by itself is\nimportant for the OVS ecosystem, because it is frequently used as a\npacket sink for tcpdump while debugging OVS deployments. And when the\nissue is hit, the only way to recover is to reboot.\n\nFix that by also checking if the device is running. The running\nstate is handled by the net core during unregistering, so it covers\nunregistering case better, and we don't really need to send packets\nto devices that are not running anyway.\n\nWhile only checking the running state might be enough, the carrier\ncheck is preserved. The running and the carrier states seem disjoined\nthroughout the code and different drivers. And other core functions\nlike __dev_direct_xmit() check both before attempting to transmit\na packet. So, it seems safer to check both flags in OVS as well.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
} ],
"affected" : [ ],
"references" : [ {
"type" : "ADVISORY",
"url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-21681"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/47e55e4b410f7d552e43011baa5be1aab4093990"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/82f433e8dd0629e16681edf6039d094b5518d8ed"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/87fcf0d137c770e6040ebfdb0abd8e7dd481b504"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/930268823f6bccb697aa5d2047aeffd4a497308c"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/b5c73fc92f8d15c16e5dc87b5c17d2abf1e6d092"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/ea966b6698785fb9cd0fdb867acd91b222e4723f"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/ea9e990356b7bee95440ba0e6e83cc4d701afaca"
}, {
"type" : "WEB",
"url" : "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-835" ],
"severity" : "MODERATE",
"github_reviewed" : false,
"github_reviewed_at" : null,
"nvd_published_at" : "2025-01-31T12:15:29Z"
}
}