CVE-2026-31503
Received Received - Intake
UDP Wildcard Bind Conflict Vulnerability in Linux Kernel

Publication date: 2026-04-22

Last updated on: 2026-04-28

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: udp: Fix wildcard bind conflict check when using hash2 When binding a udp_sock to a local address and port, UDP uses two hashes (udptable->hash and udptable->hash2) for collision detection. The current code switches to "hash2" when hslot->count > 10. "hash2" is keyed by local address and local port. "hash" is keyed by local port only. The issue can be shown in the following bind sequence (pseudo code): bind(fd1, "[fd00::1]:8888") bind(fd2, "[fd00::2]:8888") bind(fd3, "[fd00::3]:8888") bind(fd4, "[fd00::4]:8888") bind(fd5, "[fd00::5]:8888") bind(fd6, "[fd00::6]:8888") bind(fd7, "[fd00::7]:8888") bind(fd8, "[fd00::8]:8888") bind(fd9, "[fd00::9]:8888") bind(fd10, "[fd00::10]:8888") /* Correctly return -EADDRINUSE because "hash" is used * instead of "hash2". udp_lib_lport_inuse() detects the * conflict. */ bind(fail_fd, "[::]:8888") /* After one more socket is bound to "[fd00::11]:8888", * hslot->count exceeds 10 and "hash2" is used instead. */ bind(fd11, "[fd00::11]:8888") bind(fail_fd, "[::]:8888") /* succeeds unexpectedly */ The same issue applies to the IPv4 wildcard address "0.0.0.0" and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For example, if there are existing sockets bound to "192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or "[::ffff:0.0.0.0]:8888" can also miss the conflict when hslot->count > 10. TCP inet_csk_get_port() already has the correct check in inet_use_bhash2_on_bind(). Rename it to inet_use_hash2_on_bind() and move it to inet_hashtables.h so udp.c can reuse it in this fix.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-22
Last Modified
2026-04-28
Generated
2026-05-07
AI Q&A
2026-04-22
EPSS Evaluated
2026-05-05
NVD
CVE-2026-31503
EUVD
EUVD-2026-24880
Affected Vendors & Products
Showing 13 associated CPEs
Vendor Product Version / Range
linux linux_kernel 2.6.33
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.13 (inc) to 6.18.21 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.11 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.131 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.80 (exc)
linux linux_kernel From 2.6.33.1 (inc) to 6.1.168 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's UDP socket binding mechanism. When binding a UDP socket to a local address and port, the kernel uses two hash tables (hash and hash2) to detect conflicts. The issue arises because the code switches to using hash2 only after more than 10 sockets are bound to the same port.

Hash is keyed by local port only, while hash2 is keyed by both local address and local port. Due to this, when the count exceeds 10 and hash2 is used, the conflict detection can miss conflicts involving wildcard addresses (like [::]:8888 or 0.0.0.0:8888), allowing multiple sockets to bind to the same port unexpectedly.

This means that under certain conditions, the system incorrectly allows binding to a port that should be reported as already in use, potentially causing unexpected behavior in network applications.


How can this vulnerability impact me? :

This vulnerability can lead to multiple UDP sockets being bound to the same port when they should not be, due to missed conflict detection. This can cause unexpected network behavior, such as data being delivered to the wrong socket or interference between applications.

Such behavior can result in application errors, data corruption, or denial of service conditions where network communication is disrupted or unreliable.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart