CVE-2026-80714 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
ipvs: do not propagate one-packet flag to synced conns
Synced connections can be created before their destination exists. When the destination is later added, ip_vs_bind_dest() copies connection flags from the destination into cp->flags.
IP_VS_CONN_F_ONE_PACKET connections are not synced. If a synced connection inherits IP_VS_CONN_F_ONE_PACKET while it is already hashed, expiry can treat it as a one-packet connection and skip unlinking the existing conn_tab node, leaving stale hash nodes pointing at a freed struct ip_vs_conn.
Drop IP_VS_CONN_F_ONE_PACKET from destination flags when binding synced connections.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel's IP Virtual Server (IPVS) subsystem manages load balancing for network services by maintaining connection tracking tables that map client requests to backend servers. A critical flaw was identified in the logic governing how connection states are synchronized and bound to destinations within this framework. Specifically, the vulnerability arises during the process where synced connections are established prior to their corresponding destination server being available in the cluster configuration. When a destination is eventually added to the IPVS service, the function ip_vs_bind_dest() executes to associate the pending connection with that new destination. This binding operation involves copying various flags from the destination structure into the connection parameters of cp->flags to ensure consistent behavior and state management across the load balancer nodes.
The core technical flaw lies in the unconditional propagation of all destination flags, including IP_VS_CONN_F_ONE_PACKET, during this synchronization phase. Connections marked with the one-packet flag are designed for protocols that do not require persistent session tracking, such as certain UDP-based services or ICMP echoes, where a single packet exchange constitutes the entire interaction and no further state maintenance is required. These specific connection types are explicitly excluded from being synced across cluster nodes to reduce overhead and prevent state inconsistency. However, because the binding logic did not filter out this flag when applying destination attributes to already hashed connections, it was possible for a synced connection to inherit the one-packet status even after it had been inserted into the global hash table.
This inheritance creates a dangerous race condition regarding connection expiration and cleanup routines. When such a misconfigured connection expires or is terminated, the kernel's expiry logic checks its flags to determine how to handle teardown procedures. If the connection erroneously retains the IP_VS_CONN_F_ONE_PACKET flag due to the flawed binding process, the system assumes it does not need to be unlinked from the hash table because one-packet connections are typically ephemeral and do not require complex state cleanup in standard scenarios. Consequently, the existing conn_tab node remains linked despite being logically invalid or stale. This results in a use-after-free scenario where subsequent lookups or operations may access a freed struct ip_vs_conn object through these dangling pointers, leading to memory corruption, kernel panics, or potential privilege escalation if an attacker can trigger this state under controlled conditions.
From a classification perspective, this vulnerability aligns with CWE-416 Use After Free and CWE-823 Object Reference Without Removal from Container, as the connection object is effectively removed from logical tracking while remaining present in data structures that reference it. In terms of attack vectors, an adversary might exploit this by flooding the IPVS service with specific UDP or ICMP packets designed to trigger rapid creation and expiration cycles, thereby increasing the likelihood of hitting the race condition window where stale nodes are not properly unlinked. This falls under MITRE ATT&CK techniques related to resource exhaustion and potentially defense evasion if the resulting instability allows for bypassing logging or monitoring mechanisms during a kernel crash.
To mitigate this risk, it is imperative that system administrators apply the latest available patches from their Linux distribution vendors which include the fix for IPVS connection flag propagation. The patch specifically modifies ip_vs_bind_dest() to explicitly drop the IP_VS_CONN_F_ONE_PACKET flag when binding synced connections, ensuring that only appropriate flags are inherited by active hash table entries. Until updates are applied, operators should monitor system logs for signs of kernel oops or memory corruption errors related to IPVS and consider limiting the rate of new connection creations if feasible within their network architecture to reduce exposure to this specific race condition window.