This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
No vendor fix or workaround currently provided.
OpenCVE Recommended Actions
- Update the Linux kernel to a version that includes the io_uring poll race condition fix.
- If an immediate kernel upgrade is not feasible, avoid calling shutdown() immediately after a send on sockets that use the multishot receive feature.
- Restart any processes that may be stuck in a hung receive loop after applying the patch.
Generated by OpenCVE AI on April 7, 2026 at 10:36 UTC.
Tracking
Sign in to view the affected projects.
No advisories yet.
Sat, 02 May 2026 07:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Sat, 02 May 2026 06:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| Title | io_uring/poll: fix multishot recv missing EOF on wakeup race | kernel: io_uring/poll: fix multishot recv missing EOF on wakeup race |
| CPEs |
Tue, 07 Apr 2026 08:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-362 |
Sat, 04 Apr 2026 01:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-367 | |
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Fri, 03 Apr 2026 21:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-362 |
Fri, 03 Apr 2026 16:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | io_uring/poll: fix multishot recv missing EOF on wakeup race | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
Status: REJECTED
Assigner: Linux
Published:
Updated: 2026-05-02T06:17:49.349Z
Reserved: 2026-01-13T15:37:46.022Z
Link: CVE-2026-23473
No data.
Status : Rejected
Published: 2026-04-03T16:16:35.120
Modified: 2026-05-02T07:16:18.483
Link: CVE-2026-23473
OpenCVE Enrichment
Updated: 2026-04-08T19:53:37Z
-
CWE-367
Time-of-check Time-of-use (TOCTOU) Race Condition