CVE-2026-23473
published 2026-04-03CVE-2026-23473: In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix multishot recv missing EOF on wakeup race When a socket send and…
PriorityP414medium5.5
In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: fix multishot recv missing EOF on wakeup race
When a socket send and shutdown() happen back-to-back, both fire
wake-ups before the receiver's task_work has a chance to run. The first
wake gets poll ownership (poll_refs=1), and the second bumps it to 2.
When io_poll_check_events() runs, it calls io_poll_issue() which does a
recv that reads the data and returns IOU_RETRY. The loop then drains all
accumulated refs (atomic_sub_return(2) -> 0) and exits, even though only
the first event was consumed. Since the shutdown is a persistent state
change, no further wakeups will happen, and the multishot recv can hang
forever.
Check specifically for HUP in the poll loop, and ensure that another
loop is done to check for status if more than a single poll activation
is pending. This ensures we don't lose the shutdown event.
Affected
7 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.19.10-1 (forky) | linux 6.19.10-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= dbc2564cfe0faff439dc46adb8c009589054ea46 < 0f4ce79b8db7b040373fc664c8bc6c5fd74bd196 | 0f4ce79b8db7b040373fc664c8bc6c5fd74bd196 |
| linux | linux | >= dbc2564cfe0faff439dc46adb8c009589054ea46 < bf33554b6abf7e7faeadd8af1b82037ea755a6bb | bf33554b6abf7e7faeadd8af1b82037ea755a6bb |
| linux | linux | >= dbc2564cfe0faff439dc46adb8c009589054ea46 < a68ed2df72131447d131531a08fe4dfcf4fa4653 | a68ed2df72131447d131531a08fe4dfcf4fa4653 |
| linux | linux_kernel | >= 0 < 6.19.10-1 | 6.19.10-1 |
| msrc | azl3_kernel_6.6.130.1-3_on_azure_linux_3.0 | — | — |
CVSS provenance
vendor_redhat5.5MEDIUM
vendor_msrc4.7MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: io_uring/poll: fix multishot recv missing EOF on wakeup race
vendor_redhat·2026-04-03·CVSS 5.5
CVE-2026-23473 [MEDIUM] CWE-367 kernel: io_uring/poll: fix multishot recv missing EOF on wakeup race
kernel: io_uring/poll: fix multishot recv missing EOF on wakeup race
In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: fix multishot recv missing EOF on wakeup race
When a socket send and shutdown() happen back-to-back, both fire
wake-ups before the receiver's task_work has a chance to run. The first
wake gets poll ownership (poll_refs=1), and the second bumps it to 2.
When io_poll_check_events() runs, it calls io_poll_issue() which does a
recv that reads the data and returns IOU_RETRY. The loop then drains all
accumulated refs (atomic_sub_return(2) -> 0) and exits, even though only
the first event was consumed. Since the shutdown is a persistent state
change, no further wakeups will happen, and the multishot recv can hang
forever.
Check specifically for H
Microsoft
io_uring/poll: fix multishot recv missing EOF on wakeup race
vendor_msrc·2026-04-02·CVSS 4.7
CVE-2026-23473 [MEDIUM] io_uring/poll: fix multishot recv missing EOF on wakeup race
io_uring/poll: fix multishot recv missing EOF on wakeup race
Mariner: Mariner
Linux: Linux
Customer Action Required: Yes
Debian
CVE-2026-23473: linux - In the Linux kernel, the following vulnerability has been resolved: io_uring/po...
vendor_debian·2026
CVE-2026-23473 CVE-2026-23473: linux - In the Linux kernel, the following vulnerability has been resolved: io_uring/po...
In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix multishot recv missing EOF on wakeup race When a socket send and shutdown() happen back-to-back, both fire wake-ups before the receiver's task_work has a chance to run. The first wake gets poll ownership (poll_refs=1), and the second bumps it to 2. When io_poll_check_events() runs, it calls io_poll_issue() which does a recv that reads the data and returns IOU_RETRY. The loop then drains all accumulated refs (atomic_sub_return(2) -> 0) and exits, even though only the first event was consumed. Since the shutdown is a persistent state change, no further wakeups will happen, and the multishot recv can hang forever. Check specifically for HUP in the poll loop, and ensure that another loop is done to check for
VulDB
Linux Kernel up to 6.18.19/6.19.9/7.0-rc4 shutdown state issue (EUVD-2026-18746 / Nessus ID 304961)
vuldb·2026-05-03
CVE-2026-23473 [CRITICAL] Linux Kernel up to 6.18.19/6.19.9/7.0-rc4 shutdown state issue (EUVD-2026-18746 / Nessus ID 304961)
A vulnerability categorized as critical has been discovered in Linux Kernel up to 6.18.19/6.19.9/7.0-rc4. This vulnerability affects the function shutdown. Such manipulation leads to state issue.
This vulnerability is referenced as CVE-2026-23473. The attack needs to be initiated within the local network. No exploit is available.
It is advisable to upgrade the affected component.
GHSA
GHSA-c5mp-x9x5-3g5v: In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: fix multishot recv missing EOF on wakeup race
When a socket send
ghsa_unreviewed·2026-04-03
CVE-2026-23473 GHSA-c5mp-x9x5-3g5v: In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: fix multishot recv missing EOF on wakeup race
When a socket send
In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: fix multishot recv missing EOF on wakeup race
When a socket send and shutdown() happen back-to-back, both fire
wake-ups before the receiver's task_work has a chance to run. The first
wake gets poll ownership (poll_refs=1), and the second bumps it to 2.
When io_poll_check_events() runs, it calls io_poll_issue() which does a
recv that reads the data and returns IOU_RETRY. The loop then drains all
accumulated refs (atomic_sub_return(2) -> 0) and exits, even though only
the first event was consumed. Since the shutdown is a persistent state
change, no further wakeups will happen, and the multishot recv can hang
forever.
Check specifically for HUP in the poll loop, and ensure that another
loop is done to check
CVEList
io_uring/poll: fix multishot recv missing EOF on wakeup race
cvelistv5·2026-04-03
CVE-2026-23473 io_uring/poll: fix multishot recv missing EOF on wakeup race
io_uring/poll: fix multishot recv missing EOF on wakeup race
In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: fix multishot recv missing EOF on wakeup race
When a socket send and shutdown() happen back-to-back, both fire
wake-ups before the receiver's task_work has a chance to run. The first
wake gets poll ownership (poll_refs=1), and the second bumps it to 2.
When io_poll_check_events() runs, it calls io_poll_issue() which does a
recv that reads the data and returns IOU_RETRY. The loop then drains all
accumulated refs (atomic_sub_return(2) -> 0) and exits, even though only
the first event was consumed. Since the shutdown is a persistent state
change, no further wakeups will happen, and the multishot recv can hang
forever.
Check specifically for HUP in
OSV
CVE-2026-23473: In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix multishot recv missing EOF on wakeup race When a socket send an
osv·2026-04-03
CVE-2026-23473 CVE-2026-23473: In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix multishot recv missing EOF on wakeup race When a socket send an
In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix multishot recv missing EOF on wakeup race When a socket send and shutdown() happen back-to-back, both fire wake-ups before the receiver's task_work has a chance to run. The first wake gets poll ownership (poll_refs=1), and the second bumps it to 2. When io_poll_check_events() runs, it calls io_poll_issue() which does a recv that reads the data and returns IOU_RETRY. The loop then drains all accumulated refs (atomic_sub_return(2) -> 0) and exits, even though only the first event was consumed. Since the shutdown is a persistent state change, no further wakeups will happen, and the multishot recv can hang forever. Check specifically for HUP in the poll loop, and ensure that another loop is done to check for
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2026-23473 kernel: io_uring/poll: fix multishot recv missing EOF on wakeup race
bugzilla·2026-04-03
CVE-2026-23473 CVE-2026-23473 kernel: io_uring/poll: fix multishot recv missing EOF on wakeup race
CVE-2026-23473 kernel: io_uring/poll: fix multishot recv missing EOF on wakeup race
In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: fix multishot recv missing EOF on wakeup race
When a socket send and shutdown() happen back-to-back, both fire
wake-ups before the receiver's task_work has a chance to run. The first
wake gets poll ownership (poll_refs=1), and the second bumps it to 2.
When io_poll_check_events() runs, it calls io_poll_issue() which does a
recv that reads the data and returns IOU_RETRY. The loop then drains all
accumulated refs (atomic_sub_return(2) -> 0) and exits, even though only
the first event was consumed. Since the shutdown is a persistent state
change, no further wakeups will happen, and the multishot recv can hang
forever.
Check
Wiz
CVE-2026-23473 Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz
CVE-2026-23473 CVE-2026-23473 Impact, Exploitability, and Mitigation Steps | Wiz
## CVE-2026-23473 :
Linux Kernel vulnerability analysis and mitigation
In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: fix multishot recv missing EOF on wakeup race
When a socket send and shutdown() happen back-to-back, both fire
wake-ups before the receiver's task_work has a chance to run. The first
wake gets poll ownership (poll_refs=1), and the second bumps it to 2.
When io_poll_check_events() runs, it calls io_poll_issue() which does a
recv that reads the data and returns IOU_RETRY. The loop then drains all
accumulated refs (atomic_sub_return(2) -> 0) and exits, even though only
the first event was consumed. Since the shutdown is a persistent state
change, no further wakeups will happen, and the multishot recv can hang
forever.
Check specifically
2026-04-03
Published