PULSE
FEED
ransompanzer reclama a Yodingenierie · BJ · Professional Servicesransomqilin reclama a White & Case · US · Professional Servicesransomqilin reclama a Hossner-Textil GmbH · DE · Manufacturingransomwhitearmor reclama a Partido Liberal · AR · Government & Defenseransomqilin reclama a Ooredoo Myanmar · MM · Technologyransomfalcon reclama a Weitz & Luxenberg · US · Professional Servicesransomfalcon reclama a Astrana Health · US · Healthcareransomemperador reclama a A-RMS · Government & Defenseransomhyflock reclama a Aesthetic Dental Designs, P.A · US · Healthcareransomqilin reclama a ECOM · CH · Retail & E-Commerceransomemperador reclama a AyT COMPUTERS SRL · Technologyransomqilin reclama a ETO · DE · Not Foundransomn0n reclama a TOPLIVO AD · BG · Energy & Utilitiesransomn0n reclama a Technoleads Services Inc. · Technologyransompanzer reclama a Yodingenierie · BJ · Professional Servicesransomqilin reclama a White & Case · US · Professional Servicesransomqilin reclama a Hossner-Textil GmbH · DE · Manufacturingransomwhitearmor reclama a Partido Liberal · AR · Government & Defenseransomqilin reclama a Ooredoo Myanmar · MM · Technologyransomfalcon reclama a Weitz & Luxenberg · US · Professional Servicesransomfalcon reclama a Astrana Health · US · Healthcareransomemperador reclama a A-RMS · Government & Defenseransomhyflock reclama a Aesthetic Dental Designs, P.A · US · Healthcareransomqilin reclama a ECOM · CH · Retail & E-Commerceransomemperador reclama a AyT COMPUTERS SRL · Technologyransomqilin reclama a ETO · DE · Not Foundransomn0n reclama a TOPLIVO AD · BG · Energy & Utilitiesransomn0n reclama a Technoleads Services Inc. · Technology
← All CVEs
CVE WatchOct 15, 2026

CVE-2026-31503

In the Linux kernel, the following vulnerability has been resolved: udp: Fix wildcard bind conflict check when using hash2 When binding a

CVSS

5.5

Medium

EPSS

0.1%

p2

KEV

—

Exploit Today

1

0-100

Published: Apr 22, 2026 · Last modified: Oct 15, 2026

EPSS · 30d
0.1%EPSS · 30 days0.2%
2026-09-272026-10-25
Technical 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.

Official references
Related CVEs

No related CVEs by CWE or product.