CVE-2026-31503: Linux Kernel UDP DoS Vulnerability

CVE-2026-31503 Overview

CVE-2026-31503 is a vulnerability in the Linux kernel's UDP networking subsystem that affects the wildcard bind conflict detection mechanism when using the hash2 hash table. When binding a udp_sock to a local address and port, the UDP stack uses two hashes (udptable->hash and udptable->hash2) for collision detection. The vulnerability occurs when the slot count exceeds 10, causing the kernel to switch from hash to hash2, which can miss bind conflicts for wildcard addresses.

Critical Impact

Allows UDP sockets to bind to wildcard addresses (:: or 0.0.0.0) even when existing sockets are already bound to specific addresses on the same port, potentially enabling network traffic interception or denial of service conditions.

Affected Products

• Linux Kernel (multiple stable branches)
• Systems using IPv6 wildcard binding (:: port bindings)
• Systems using IPv4 wildcard binding (0.0.0.0 port bindings)

Discovery Timeline

• 2026-04-22 - CVE-2026-31503 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-31503

Vulnerability Analysis

The vulnerability exists in the UDP socket binding logic within the Linux kernel networking stack. The UDP subsystem maintains two hash tables for socket lookups: hash (keyed by local port only) and hash2 (keyed by both local address and local port). When a hash slot's count exceeds 10, the kernel switches to using hash2 for conflict detection via udp_lib_lport_inuse().

The issue arises because hash2 is keyed by both address and port. When checking for wildcard address conflicts (such as [::] or 0.0.0.0), the hash2 lookup fails to detect existing sockets bound to specific addresses on the same port. This allows a wildcard bind to succeed when it should return -EADDRINUSE.

The vulnerability affects both IPv6 wildcard address (::) and IPv4 wildcard address (0.0.0.0), as well as the IPv4-mapped wildcard address (::ffff:0.0.0.0).

Root Cause

The root cause is an inconsistency in how the UDP stack handles wildcard bind conflict checks when switching from hash to hash2. The hash table, keyed only by port, correctly detects conflicts with existing sockets on the same port regardless of their bound addresses. However, hash2, being keyed by both address and port, looks up a different slot for wildcard addresses than for specific addresses, causing it to miss legitimate conflicts.

The TCP stack already handles this correctly through inet_use_bhash2_on_bind() in inet_csk_get_port(). The fix renames this function to inet_use_hash2_on_bind() and moves it to inet_hashtables.h so UDP can reuse the same logic.

Attack Vector

The attack scenario involves binding multiple UDP sockets to specific addresses on the same port (e.g., 11+ sockets to addresses like [fd00::1]:8888 through [fd00::11]:8888). Once the slot count exceeds 10, an attacker can then bind to the wildcard address on the same port, which should fail but incorrectly succeeds. This could allow:

1. Interception of network traffic intended for the specific addresses
2. Service disruption by competing for incoming packets
3. Bypassing application-level access controls that rely on bind semantics

The bind sequence demonstrating the vulnerability:

After binding 10 sockets to specific IPv6 addresses on port 8888, binding to [::]:8888 correctly fails with EADDRINUSE. However, after binding an 11th socket (triggering the hash2 switch), a subsequent wildcard bind unexpectedly succeeds, violating expected socket binding semantics.

Detection Methods for CVE-2026-31503

Indicators of Compromise

• Unexpected successful UDP wildcard binds in application logs when specific address binds exist
• Multiple UDP sockets bound to overlapping address spaces on the same port
• Network traffic anomalies where packets are received by unexpected sockets
• Application failures due to socket binding conflicts not being properly detected

Detection Strategies

• Monitor kernel logs for unusual UDP socket binding patterns
• Use ss -ulnp or netstat -ulnp to audit UDP socket bindings for potential overlaps
• Implement application-level logging around socket bind operations to detect unexpected successes
• Deploy network monitoring to identify traffic routing anomalies

Monitoring Recommendations

• Enable detailed kernel networking audit logs
• Monitor for high numbers of UDP socket binds to the same port from different processes
• Set up alerts for wildcard binds on ports with existing specific address bindings
• Review application deployment configurations for potential exposure

How to Mitigate CVE-2026-31503

Immediate Actions Required

• Update the Linux kernel to a patched version from the stable branches
• Review application socket binding configurations for potential exposure
• Implement application-level validation of socket binding results
• Consider using SO_REUSEPORT with caution and understand its implications

Patch Information

The Linux kernel developers have released patches across multiple stable branches. The fix involves reusing the TCP stack's inet_use_bhash2_on_bind() logic (renamed to inet_use_hash2_on_bind()) in the UDP binding code path.

Patches are available at the following kernel git commits:

• Kernel Git Commit 0a360f7
• Kernel Git Commit 18d84c4
• Kernel Git Commit 2297e38
• Kernel Git Commit d6ace0d
• Kernel Git Commit e537dd1
• Kernel Git Commit f1bed05

Workarounds

• Avoid deploying applications that rely on wildcard UDP binds in environments with high socket counts per port
• Implement application-level checks to verify bind exclusivity before trusting kernel responses
• Use network namespaces to isolate applications with conflicting binding requirements
• Consider using TCP where appropriate instead of UDP for services requiring strict bind semantics

# Check current UDP socket bindings on a specific port
ss -ulnp sport = :8888

# Monitor for potential overlapping binds
watch -n 5 'ss -ulnp | grep ":8888"'