Public mode

No access to your tenant or devices. Every item links to its source. What this means

Some sources, documents or advisories need attention: 275/275 feeds/APIs · 469/469 docs · 8/9 advisories · checked 00:13 UTC Customize Public modeDiscuss ChangeIntel on Discord

udp: remove a disconnected socket from the 4-tuple hash table

Assessment

Severity
Unrated
CVSS base score
Not published
Impact
Not stated
EPSS · 30-day forecast
No EPSS score collected
Public detection template
No Nuclei template is listed in the current collected catalog
Exploitation detected
Unknown: not stated by MSRC
Exploitability
Not assessed
Publicly disclosed
Unknown: not stated by MSRC
Customer action
Required: follow the MSRC remediation guidance
Component
Mariner
Weakness
—
Issued by
Linux
Published
20 Oct 2026 · October 2026
Last revised
20 Oct 2026

Updates that fix it

0 KBs

No KB listed

No KB update is listed in the collected MSRC record. Check the MSRC advisory for product releases and other remedies.

What changed

  1. Detection template: Unknown: detection-template evidence is incomplete or retained → No Nuclei template listed
  2. Detection template: No Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
  3. Detection template: Unknown: detection-template evidence is incomplete or retained → No Nuclei template listed
  4. Detection template: No Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
  5. Detection template: No Nuclei template listed · Customer action: Required: apply the update → Required: follow the MSRC remediation guidance · Public disclosure: No → Unknown: not stated by MSRC · Exploitation detected: Not reported by MSRC → Unknown: not stated by MSRC
  6. Detection template: Unknown: exploit-code evidence is incomplete or retained → No Nuclei template listed · CISA KEV: Unknown: catalog evidence is incomplete or retained → Not listed in the collected catalog
  7. Detection template: No Nuclei template listed → Unknown: exploit-code evidence is incomplete or retained · CISA KEV: Not listed in the collected catalog → Unknown: catalog evidence is incomplete or retained
Page history

Changes are dated when recorded; day views use the last saved version from that UTC day, and citations stay fixed.

Cite this version
Field-level log (33)

Up to 100 recent field edits are shown; older edits may be outside retention.

  1. 6 Nov 2026 · 17:32:22 UTC Public detection templateUnknown: detection-template evidence is incomplete or retained → No Nuclei template listed
  2. 6 Nov 2026 · 17:32:22 UTC Source coverage: public-exploit-codeIncomplete → Current
  3. 6 Nov 2026 · 17:32:22 UTC Source coverage: first-epssIncomplete → Current
  4. 6 Nov 2026 · 17:32:22 UTC Source coverage: msrc-cvrfIncomplete → Current
  5. 6 Nov 2026 · 16:31:02 UTC Public detection templateNo Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
  6. 6 Nov 2026 · 16:31:02 UTC Source coverage: public-exploit-codeCurrent → Incomplete
  7. 6 Nov 2026 · 16:31:02 UTC Source coverage: first-epssCurrent → Incomplete
  8. 6 Nov 2026 · 16:31:02 UTC Source coverage: msrc-cvrfCurrent → Incomplete
  9. 2 Nov 2026 · 17:30:39 UTC Public detection templateUnknown: detection-template evidence is incomplete or retained → No Nuclei template listed
  10. 2 Nov 2026 · 17:30:39 UTC Source coverage: public-exploit-codeIncomplete → Current
  11. 2 Nov 2026 · 17:30:39 UTC Source coverage: first-epssIncomplete → Current
  12. 2 Nov 2026 · 17:30:39 UTC Source coverage: msrc-cvrfIncomplete → Current
  13. 2 Nov 2026 · 16:27:39 UTC Public detection templateNo Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
  14. 2 Nov 2026 · 16:27:39 UTC Source coverage: public-exploit-codeCurrent → Incomplete
  15. 2 Nov 2026 · 16:27:39 UTC Source coverage: first-epssCurrent → Incomplete
  16. 2 Nov 2026 · 16:27:39 UTC Source coverage: msrc-cvrfCurrent → Incomplete
  17. 29 Oct 2026 · 20:19:26 UTC Public detection templateNo Nuclei template listed
  18. 29 Oct 2026 · 20:19:26 UTC EPSSNot scored → No EPSS score collected
  19. 29 Oct 2026 · 20:19:26 UTC Customer actionRequired: apply the update → Required: follow the MSRC remediation guidance
  20. 29 Oct 2026 · 20:19:26 UTC Publicly disclosedNo → Unknown: not stated by MSRC
  21. 29 Oct 2026 · 20:19:26 UTC Exploitation detectedNot reported by MSRC → Unknown: not stated by MSRC
  22. 23 Oct 2026 · 09:33:49 UTC Public exploit codeUnknown: exploit-code evidence is incomplete or retained → No Nuclei template listed
  23. 23 Oct 2026 · 09:33:49 UTC CISA KEVUnknown: catalog evidence is incomplete or retained → Not listed in the collected catalog
  24. 23 Oct 2026 · 09:33:49 UTC Source coverage: public-exploit-codeIncomplete → Current
  25. 23 Oct 2026 · 09:33:49 UTC Source coverage: first-epssIncomplete → Current
  26. 23 Oct 2026 · 09:33:49 UTC Source coverage: cisa-kevIncomplete → Current
  27. 23 Oct 2026 · 09:33:49 UTC Source coverage: msrc-cvrfIncomplete → Current
  28. 23 Oct 2026 · 08:31:50 UTC Public exploit codeNo Nuclei template listed → Unknown: exploit-code evidence is incomplete or retained
  29. 23 Oct 2026 · 08:31:50 UTC CISA KEVNot listed in the collected catalog → Unknown: catalog evidence is incomplete or retained
  30. 23 Oct 2026 · 08:31:50 UTC Source coverage: public-exploit-codeCurrent → Incomplete
  31. 23 Oct 2026 · 08:31:50 UTC Source coverage: first-epssCurrent → Incomplete
  32. 23 Oct 2026 · 08:31:50 UTC Source coverage: cisa-kevCurrent → Incomplete
  33. 23 Oct 2026 · 08:31:50 UTC Source coverage: msrc-cvrfCurrent → Incomplete

Explore global source statements, affected packages and advisory history for CVE-2026-98595. The catalog has a separate collection scope from Microsoft release records.

Collected exploitation and prediction evidence

Risk source coverage

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

cve-program · CVE-2026-98595

Published

udp: remove a disconnected socket from the 4-tuple hash table

In the Linux kernel, the following vulnerability has been resolved: udp: remove a disconnected socket from the 4-tuple hash table A UDP socket bound to a specific address and port keeps its entry in the 4-tuple hash table after it is disconnected: sk binds to 127.0.0.1:21001 sk connects to 127.0.0.2:20001 // filed in the 4-tuple table sk disconnects, connect(AF_UNSPEC) // still filed, peer now 0.0.0.0:0 __udp_disconnect() takes a socket out of that table only as a side effect of ->rehash() or ->unhash(), and it skips ->rehash() when SOCK_BINDADDR_LOCK is set and ->unhash() when SOCK_BINDPORT_LOCK is set. commit 6996a2d2d0a6 ("udp: Unhash auto-bound connected sk from 4-tuple hash table when disconnected.") fixed the same end state for a wildcard-bound socket, by a path this one does not take. The entry is counted whether or not anything hits it. hash4_cnt on the hash2 slot stays raised for as long as the socket lives, so udp_has_hash4() keeps sending every packet for that address and port through the 4-tuple lookup first. On IPv6 it can also be hit. __udp_disconnect() does not clear sk_v6_daddr, so udp_v6_rehash() files the entry under the peer the socket was connected to with a zero dport, and inet6_match() compares that same field: a datagram from the former peer with a zero source port matches, and source port zero is accepted on receive. On IPv4 the peer is cleared, so a match would need a zero source address as well, which the routing layer rejects as martian. The stale sk_v6_daddr is a separate defect, not addressed here; removing the entry closes this path either way. The entry can also be relocated. __udp_disconnect() clears sk_bound_dev_if, so a subsequent SO_BINDTODEVICE calls ->rehash(), and because the receive address is still specific udp_lib_rehash() moves the entry instead of removing it, into the bucket that (rcv_saddr, num, 0, 0) hashes to -- a pure function of the address and port, so every socket reaching this state on one address and port collects in one bucket. The bucket cannot be chosen from outside, as udp_ehashfn() is seeded with a per-boot secret. This last one became reachable only with commit 644f9108f3a5 ("udp: Make rehash4 independent in udp_lib_rehash()"), which moved the hash4 handling out of a branch a disconnected socket does not take; the stale entry itself dates from the commit in Fixes. Take the socket out of the table before __udp_disconnect() runs, while it still matches how it was filed. This also reaches the wildcard case ahead of udp_lib_rehash()'s udp_unhash4() branch, leaving that branch unreachable from udp_disconnect(); removing it belongs in net-next. udp_disconnect() and udp_abort() are the only UDP entries into __udp_disconnect(), which is shared with raw, ping and l2tp sockets that are not struct udp_sock: ping_prot.obj_size is sizeof(struct inet_sock), so udp_hashed4() on one would read past the allocation.

Source published
18 Oct 2026 15:19:07 UTC
Source modified
19 Oct 2026 09:22:20 UTC
Observed here
23 Oct 2026 15:48:27 UTC
Source terms
CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

ChangeIntel

An IT change radar: releases, security, known issues, retirements, documentation changes, and service status from public sources. Every item links to supporting evidence; dates and statuses can change after they are read.

Sources read 9 Nov 00:13 UTC · 275 of 275 readable · 273 fully read · documentation 469/469 current