CVE-2026-23331 in Linux
Summary
by MITRE • 03/25/2026
In the Linux kernel, the following vulnerability has been resolved:
udp: Unhash auto-bound connected sk from 4-tuple hash table when disconnected.
Let's say we bind() an UDP socket to the wildcard address with a non-zero port, connect() it to an address, and disconnect it from the address.
bind() sets SOCK_BINDPORT_LOCK on sk->sk_userlocks (but not SOCK_BINDADDR_LOCK), and connect() calls udp_lib_hash4() to put the socket into the 4-tuple hash table.
Then, __udp_disconnect() calls sk->sk_prot->rehash(sk).
It computes a new hash based on the wildcard address and moves the socket to a new slot in the 4-tuple hash table, leaving a garbage in the chain that no packet hits.
Let's remove such a socket from 4-tuple hash table when disconnected.
Note that udp_sk(sk)->udp_portaddr_hash needs to be udpated after udp_hash4_dec(hslot2) in udp_unhash4().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/31/2026
This vulnerability exists within the Linux kernel's UDP networking implementation where a socket management inconsistency occurs during the disconnect operation of auto-bound connected sockets. The issue stems from how the kernel handles socket hash table entries when a socket transitions from a connected state back to a disconnected state. When an application binds a UDP socket to a wildcard address with a non-zero port, then connects to a specific address, and subsequently disconnects, the kernel fails to properly remove the socket from the 4-tuple hash table. This creates a dangling hash table entry that remains in the hash chain but no longer corresponds to a valid socket state, potentially leading to packet routing confusion or resource waste.
The technical flaw manifests in the interaction between multiple kernel subsystems where bind() operation sets SOCK_BINDPORT_LOCK in the socket's user locks but leaves SOCK_BINDADDR_LOCK unset, indicating that only the port binding is locked while the address binding remains flexible. When connect() is called, the udp_lib_hash4() function places the socket into the 4-tuple hash table using the complete 4-tuple information. However, during the disconnect phase, __udp_disconnect() invokes sk->sk_prot->rehash(sk) which computes a new hash based on the wildcard address but fails to completely remove the original hash table entry. This creates a memory leak scenario where the hash table contains stale references that no incoming packets can match, leading to potential denial of service conditions or resource exhaustion.
The operational impact of this vulnerability extends beyond simple memory waste to potentially affect network performance and system stability. The garbage entries left in the hash table chains can cause increased lookup times for valid socket entries, creating performance degradation in high-traffic networking scenarios. Network administrators may observe unexpected behavior in UDP socket management, particularly in applications that frequently establish and tear down connections. The vulnerability affects systems using the Linux kernel's UDP stack where auto-bound sockets are common, such as in web servers, DNS resolvers, and other network services that handle dynamic connection patterns. The issue is particularly concerning in environments with high socket turnover rates where the accumulation of stale hash table entries can lead to significant performance degradation.
The fix addresses this by ensuring proper hash table cleanup during disconnection operations, specifically requiring that udp_unhash4() properly decrements the hash slot reference count and updates the udp_portaddr_hash value after calling udp_hash4_dec(hslot2). This remediation follows established security principles for proper resource management and hash table maintenance. The vulnerability aligns with CWE-457: Use of Uninitialized Variable and CWE-772: Missing Release of Resource after Effective Lifetime, as it represents improper resource cleanup in the kernel's socket management subsystem. From an ATT&CK perspective, this vulnerability could be leveraged in resource exhaustion attacks or potentially used as a stepping stone for more sophisticated network-based attacks. The fix ensures that socket hash table entries are properly removed when sockets transition from connected to disconnected states, maintaining the integrity of the kernel's networking subsystem and preventing potential exploitation scenarios that could arise from stale hash table entries.