The Linux kernel’s UDP implementation maintains two hash tables for binding sockets: a primary hash keyed only by port and a secondary hash keyed by both local address and port. When more than ten sockets are bound to the same port, the kernel switches to the secondary hash. The bug arises because the conflict check for wildcard binds (e.g., "[::]:port" or "0.0.0.0:port") is not performed when the secondary hash is active, allowing a wildcard bind that should be refused to succeed. The defect applies to both IPv4 and IPv6 families, including IPv4‑mapped IPv6 addresses, and results in a port being bound unexpectedly by a wildcard socket, potentially disrupting service by misdirecting traffic intended for specific address bindings. The flaw can be triggered locally on the host: any user with the ability to create sockets on the affected ports can repeatedly bind sockets under different addresses to bring the hash count above the threshold and then attempt a wildcard bind that succeeds when it should not. This local binding behavior does not grant remote code execution or privilege escalation. The vulnerability is reflected in a CVSS score of 5.5 and an EPSS score of less than 1%, indicating a low probability of exploitation. It is not listed in the CISA KEV catalog. The primary risk is local denial of service, affecting port isolation on the host, and it is unlikely to be used as part of a broader attack.

All versions of the Linux kernel that implement the described UDP binding logic are susceptible. The provided CPE data includes the generic Linux kernel and specific release candidates 2.6.33 and 7.0 RC1 through RC7. Any host running one of these kernel versions may experience the issue when more than ten sockets are bound to the same port under different addresses.

The CVSS score of 5.5 places the flaw in a moderate severity range, while the EPSS score of less than 1% suggests a very low chance of widespread exploitation. Because the attack vector is local, any user capable of binding sockets below the privileged port range can trigger the bug. No remote exploitation path exists, and the flaw does not provide privilege escalation. Overall, the risk is moderate, largely limited to local service disruption.