CVE-2025-21958 in Linux
Summary
by MITRE • 04/01/2025
In the Linux kernel, the following vulnerability has been resolved:
Revert "openvswitch: switch to per-action label counting in conntrack"
Currently, ovs_ct_set_labels() is only called for confirmed conntrack entries (ct) within ovs_ct_commit(). However, if the conntrack entry does not have the labels_ext extension, attempting to allocate it in ovs_ct_get_conn_labels() for a confirmed entry triggers a warning in nf_ct_ext_add():
WARN_ON(nf_ct_is_confirmed(ct));
This happens when the conntrack entry is created externally before OVS increments net->ct.labels_used. The issue has become more likely since commit fcb1aa5163b1 ("openvswitch: switch to per-action label counting in conntrack"), which changed to use per-action label counting and increment net->ct.labels_used when a flow with ct action is added.
Since there’s no straightforward way to fully resolve this issue at the moment, this reverts the commit to avoid breaking existing use cases.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 02/01/2026
The vulnerability CVE-2025-21958 represents a critical issue within the Linux kernel's Open vSwitch implementation that stems from improper handling of conntrack label extensions during connection tracking operations. This flaw specifically affects the openvswitch module's interaction with the netfilter conntrack subsystem, where the kernel attempts to manage connection tracking labels for network flows. The vulnerability manifests when the system encounters conntrack entries that lack the necessary labels_ext extension, creating a scenario where the kernel's internal warning mechanisms are triggered during normal operation. The issue directly impacts the stability and reliability of network virtualization environments that depend on Open vSwitch for traffic management and connection tracking.
The technical root cause of this vulnerability lies in the improper sequence of operations within the conntrack processing pipeline. When ovs_ct_set_labels() is invoked for confirmed conntrack entries within ovs_ct_commit(), the system attempts to allocate labels_ext for entries that may have been created externally before Open vSwitch had the opportunity to increment the net->ct.labels_used counter. The function ovs_ct_get_conn_labels() triggers a warning through the nf_ct_ext_add() call when it encounters a confirmed entry that lacks the labels extension, specifically triggering the WARN_ON(nf_ct_is_confirmed(ct)) condition. This occurs because the system attempts to add extension data to entries that are already confirmed, violating the expected state management within the netfilter subsystem. This particular pattern of behavior is exacerbated by the changes introduced in commit fcb1aa5163b1, which implemented per-action label counting that modified when and how the labels_used counter is incremented during flow processing.
The operational impact of this vulnerability extends beyond simple warning messages to potentially destabilizing network virtualization environments that rely on Open vSwitch for traffic management. When this condition is triggered, it can cause unexpected behavior in connection tracking operations, leading to potential packet loss, connection timeouts, or complete disruption of network services within virtualized environments. The vulnerability particularly affects deployments where external systems create conntrack entries before Open vSwitch processes them, creating a race condition between the external entry creation and the internal label extension allocation. This issue becomes more prevalent in high-throughput network environments where connection tracking is actively managed, potentially causing cascading failures in network infrastructure that depends on stable connection tracking behavior. The warning messages generated by this vulnerability can also overwhelm system logs and monitoring systems, making it difficult to identify legitimate operational issues from the noise generated by this bug.
The mitigation strategy for this vulnerability involves reverting the problematic commit fcb1aa5163b1 that introduced the per-action label counting mechanism, effectively restoring the previous behavior that avoided the conflict between external conntrack entry creation and internal label extension allocation. This approach aligns with the principle of least privilege and system stability, as it prevents the triggering of the warning condition that leads to potential operational disruptions. Organizations should ensure that their Open vSwitch deployments are updated to versions that include this revert, particularly in production environments where network stability is critical. The solution also highlights the importance of careful consideration when implementing changes to core kernel subsystems, as modifications to connection tracking behavior can have far-reaching implications for network virtualization platforms. This vulnerability serves as a reminder of the complexity involved in managing shared kernel resources and the need for thorough testing of changes that affect fundamental networking components, particularly those that interact with the netfilter subsystem through the conntrack framework. The issue demonstrates how seemingly minor changes to label counting mechanisms can introduce significant stability concerns in production network environments.
This vulnerability maps to CWE-691, which covers insufficient control flow management, and aligns with ATT&CK technique T1562.007 for "Impairing Security Tools" through the potential disruption of network monitoring and security infrastructure. The issue also relates to T1071.004 for "Application Layer Protocol: DNS" and T1046 for "Network Service Scanning" due to its impact on network connectivity and monitoring capabilities. The warning generation mechanism in the kernel's netfilter subsystem represents a security control that, when triggered improperly, can interfere with normal operational monitoring and incident response procedures. The vulnerability demonstrates how kernel-level networking components can become unstable when external systems interact with internal state management mechanisms, potentially creating attack vectors for denial-of-service scenarios or information disclosure through log flooding.