CVE-2026-31503

What it actually does

This is a local Linux kernel UDP socket binding flaw in the logic that checks whether a wildcard UDP bind conflicts with existing address-specific binds on the same port. When more than 10 sockets are already bound to the same UDP port on different local addresses, the kernel switches from a port-only hash table to an address-and-port hash table for lookup. In the vulnerable logic, wildcard addresses such as 0.0.0.0, ::, and IPv4-mapped ::ffff:0.0.0.0 can miss conflicts that should have returned EADDRINUSE. The result is that a UDP wildcard socket can be bound to a port that is already occupied by address-specific sockets, violating expected exclusivity and potentially disrupting UDP packet delivery or application availability. The vulnerability requires local execution with the ability to create/bind UDP sockets; it does not provide remote code execution or privilege escalation by itself.

Why it matters to the business

A local user or compromised low-privilege process on an affected Linux system may be able to interfere with UDP services by creating conflicting socket binds that should normally be rejected. This can cause application startup failures, unreliable UDP traffic handling, or service disruption for workloads that depend on predictable UDP port binding behavior, such as DNS, logging, telemetry, VPN, service discovery, or custom UDP-based applications. The CVSS availability impact is high, but exploitation is local, EPSS is very low and stable, there is no known CISA KEV listing, no known ransomware association, and no reported mature public exploitation, so broad internet-facing urgency is lower than for remotely exploitable kernel flaws. Risk is higher on shared Linux hosts, multi-user systems, container hosts, CI runners, and platforms where untrusted or semi-trusted workloads can create UDP sockets.

How an attack unfolds

An attacker first obtains the ability to run code locally on an affected Linux system. They choose a UDP port they want to disrupt and create more than 10 UDP sockets bound to that same port across different local IPv4, IPv6, or IPv4-mapped addresses. This forces the UDP bind-conflict logic to use the secondary hash table keyed by local address and port. The attacker then attempts a wildcard bind on the same UDP port, such as 0.0.0.0:PORT, [::]:PORT, or [::ffff:0.0.0.0]:PORT. On vulnerable kernels, the wildcard bind can succeed even though it should conflict with existing address-specific sockets. Once the inconsistent bind state exists, UDP service behavior can become unpredictable, allowing the attacker to interfere with application availability, prevent expected services from binding cleanly, or disrupt packet handling for services relying on that UDP port. Known exploitation requires local privileges and socket creation capability; there is no indication from the supplied intelligence of active exploitation by named threat actors.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the upstream fix for the UDP wildcard bind conflict check when using hash2. Because no exact fixed package versions were provided, remediation should be based on vendor advisories for the deployed distribution and kernel stream. Where source-level validation is used, the fixed kernel contains the corrected shared bind-selection logic using inet_use_hash2_on_bind() and applies the wildcard-conflict check to UDP. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, isolating containers and tenants, applying least privilege to services, and monitoring for unusual processes creating large numbers of UDP binds on the same port. Containerized environments should update the host kernel; updating container images alone will not fix a vulnerable host kernel.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version maps to a vendor release containing the UDP hash2 wildcard bind fix. Reboot into the patched kernel after installation and ensure uname -r reflects the updated kernel. For source-based or custom kernels, confirm that the UDP bind logic reuses the corrected inet_use_hash2_on_bind() behavior and properly handles wildcard address conflicts. Functional validation can be performed in a controlled test environment by binding more than 10 UDP sockets to the same port on distinct local addresses and then attempting to bind a wildcard UDP socket on that port; a fixed kernel should reject the conflicting wildcard bind with EADDRINUSE. Avoid running proof-of-concept tests on production systems because they can interfere with UDP services.

Typical attack path

1. Gain local code execution or an interactive account on an affected Linux system.
2. Identify a UDP port used by, or valuable to, a target service.
3. Create more than 10 UDP sockets bound to the same port on different local IPv4, IPv6, or IPv4-mapped addresses.
4. Trigger the kernel path that switches UDP bind-conflict checks from the primary port-only hash to the secondary address-and-port hash.
5. Bind a wildcard UDP socket on the same port, such as 0.0.0.0:PORT or [::]:PORT, which should be rejected but may succeed on vulnerable kernels.
6. Use the conflicting bind state to disrupt UDP service behavior, cause application errors, or reduce availability.

How to detect it

There is no single reliable file, network, or process indicator that proves exploitation of this kernel logic flaw. Detection should focus on behavioral evidence from local telemetry. Review auditd, eBPF, endpoint detection, process accounting, and application logs for processes that repeatedly call bind() on UDP sockets using the same port across many different local addresses, followed by a wildcard bind to 0.0.0.0, ::, or ::ffff:0.0.0.0 on that same port. Investigate UDP services that experienced unexplained EADDRINUSE errors, unexpected successful duplicate binds, dropped UDP traffic, or startup failures. Useful data sources include Linux audit syscall logs for socket and bind activity, eBPF socket tracing, ss/netstat snapshots, systemd service logs, application bind/listen errors, container runtime telemetry, and EDR process lineage. Because successful exploitation requires local execution, correlate suspicious UDP bind behavior with new local accounts, unexpected shells, cron/systemd persistence, container escape indicators, or unusual processes running under low-privilege users. No named threat actors, public exploit artifacts, or malware-specific indicators were provided.

What your security team should do

• Prioritize patching shared Linux systems, container hosts, bastion hosts, CI/CD runners, HPC systems, and any environment where untrusted local users or workloads can create UDP sockets.
• Track Linux distribution advisories for the deployed kernel branches and schedule a reboot into a fixed kernel once available.
• Inventory systems running custom, mainline, or self-compiled kernels and confirm the UDP hash2 bind-conflict patch has been backported.
• For multi-tenant platforms, reduce local attack surface by restricting interactive access, enforcing workload isolation, and limiting unnecessary capabilities.
• Monitor for local processes creating unusually high numbers of UDP sockets bound to the same port across multiple local addresses.
• Treat suspicious exploitation attempts as a potential sign of prior local compromise, because the vulnerability requires local code execution or a local account.
• Do not rely on container image updates alone; ensure the host kernel itself is updated.