udp: Fix wildcard bind conflict check when using hash2 (Linux Linux)

CVE-2026-31503
MEDIUM 5.5

At a glance

Source
NVD
EPSS
EPSS 0.13 % · percentile 2 ()
State
PUBLISHED
Published
Updated
Assigner
Linux
NVD status
Modified

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.

References

Scores

VersionScoreVectorScored by
CVSS 3.1MEDIUM 5.5CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HNVD · nvd@nist.gov (Primary)

European references

CERT-FR advisories

Affected configurations (NVD CPE)

Affected products

ProductVersions
Linux · Linuxaffected 30fff9231fad757c061285e347b33c5149c2c2e4 < d6ace0dbcbb7fd285738bb87b42b71b01858c952 ; affected 30fff9231fad757c061285e347b33c5149c2c2e4 < 2297e38114316b26ae02f2d205c49b5511c5ed55 ; affected 30fff9231fad757c061285e347b33c5149c2c2e4 < f1bed05a832ae79be5f7a105da56810eaa59a5f1 ; affected 30fff9231fad757c061285e347b33c5149c2c2e4 < 18d84c45def3671d5c89fbdd5d4ab8a3217fe4b4 ; affected 30fff9231fad757c061285e347b33c5149c2c2e4 < 0a360f7f73a06ac88f18917055fbcc79694252d7 ; affected 30fff9231fad757c061285e347b33c5149c2c2e4 < e537dd15d0d4ad989d56a1021290f0c674dd8b28
Linux · Linuxaffected 2.6.33 ; unaffected 0 < 2.6.33 ; unaffected 6.1.168 ≤ 6.1.* ; unaffected 6.6.131 ≤ 6.6.* ; unaffected 6.12.80 ≤ 6.12.* ; unaffected 6.18.21 ≤ 6.18.*

Sources

SourceLicence
CVE List (CVEProject cvelistV5)CVE Program Terms of Use
EPSS (FIRST.org)FIRST — attribution requested
ENISA EUVDENISA — reproduction authorised, source acknowledged
CERT-FR (ANSSI)Licence Ouverte / Etalab 2.0
NVD (NIST) via fkie-cad/nvd-json-data-feedsPublic domain — this product uses data from the NVD API but is not endorsed or certified by the NVD