GHSA-8G49-X5X5-4C9C
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-28 15:30In 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.
{
"affected": [],
"aliases": [
"CVE-2026-31503"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix wildcard bind conflict check when using hash2\n\nWhen binding a udp_sock to a local address and port, UDP uses\ntwo hashes (udptable-\u003ehash and udptable-\u003ehash2) for collision\ndetection. The current code switches to \"hash2\" when\nhslot-\u003ecount \u003e 10.\n\n\"hash2\" is keyed by local address and local port.\n\"hash\" is keyed by local port only.\n\nThe issue can be shown in the following bind sequence (pseudo code):\n\nbind(fd1, \"[fd00::1]:8888\")\nbind(fd2, \"[fd00::2]:8888\")\nbind(fd3, \"[fd00::3]:8888\")\nbind(fd4, \"[fd00::4]:8888\")\nbind(fd5, \"[fd00::5]:8888\")\nbind(fd6, \"[fd00::6]:8888\")\nbind(fd7, \"[fd00::7]:8888\")\nbind(fd8, \"[fd00::8]:8888\")\nbind(fd9, \"[fd00::9]:8888\")\nbind(fd10, \"[fd00::10]:8888\")\n\n/* Correctly return -EADDRINUSE because \"hash\" is used\n * instead of \"hash2\". udp_lib_lport_inuse() detects the\n * conflict.\n */\nbind(fail_fd, \"[::]:8888\")\n\n/* After one more socket is bound to \"[fd00::11]:8888\",\n * hslot-\u003ecount exceeds 10 and \"hash2\" is used instead.\n */\nbind(fd11, \"[fd00::11]:8888\")\nbind(fail_fd, \"[::]:8888\") /* succeeds unexpectedly */\n\nThe same issue applies to the IPv4 wildcard address \"0.0.0.0\"\nand the IPv4-mapped wildcard address \"::ffff:0.0.0.0\". For\nexample, if there are existing sockets bound to\n\"192.168.1.[1-11]:8888\", then binding \"0.0.0.0:8888\" or\n\"[::ffff:0.0.0.0]:8888\" can also miss the conflict when\nhslot-\u003ecount \u003e 10.\n\nTCP inet_csk_get_port() already has the correct check in\ninet_use_bhash2_on_bind(). Rename it to\ninet_use_hash2_on_bind() and move it to inet_hashtables.h\nso udp.c can reuse it in this fix.",
"id": "GHSA-8g49-x5x5-4c9c",
"modified": "2026-04-28T15:30:47Z",
"published": "2026-04-22T15:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31503"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a360f7f73a06ac88f18917055fbcc79694252d7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18d84c45def3671d5c89fbdd5d4ab8a3217fe4b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2297e38114316b26ae02f2d205c49b5511c5ed55"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d6ace0dbcbb7fd285738bb87b42b71b01858c952"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e537dd15d0d4ad989d56a1021290f0c674dd8b28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1bed05a832ae79be5f7a105da56810eaa59a5f1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.