io_uring/poll: fix multishot recv missing EOF on wakeup race

From: Jens Axboe <[email protected]>

[ Upstream commit a68ed2df72131447d131531a08fe4dfcf4fa4653 ]

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.

Backport notes for linux-6.12.y:
- The do-while body in 6.12.y already places v &= IO_POLL_REF_MASK; just before the while-condition; the upstream patch moves it earlier so that v != 1 in the HUP check refers to the ref-count only. The backport does the same.
- io_poll_issue takes ts (struct io_tw_state *) here.

CVE: CVE-2026-23473

---
 io_uring/poll.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

@@ -297,6 +297,7 @@ static int io_poll_check_events(struct io_kiocb *req, struct io_tw_state *ts)
 				atomic_andnot(IO_POLL_RETRY_FLAG, &req->poll_refs);
 				v &= ~IO_POLL_RETRY_FLAG;
 			}
+			v &= IO_POLL_REF_MASK;
 		}
 
 		/* the mask was stashed in __io_poll_execute */

@@ -327,7 +328,12 @@ static int io_poll_check_events(struct io_kiocb *req, struct io_tw_state *ts)
 				return IOU_POLL_REMOVE_POLL_USE_RES;
 			}
 		} else {
-			int ret = io_poll_issue(req, ts);
+			int ret;
+
+			/* multiple refs and HUP, ensure we loop once more */
+			if ((req->cqe.res & (POLLHUP | POLLRDHUP)) && v != 1)
+				v--;
+			ret = io_poll_issue(req, ts);
 			if (ret == IOU_STOP_MULTISHOT)
 				return IOU_POLL_REMOVE_POLL_USE_RES;
 			else if (ret == IOU_REQUEUE)

@@ -343,7 +349,6 @@ static int io_poll_check_events(struct io_kiocb *req, struct io_tw_state *ts)
 		 * Release all references, retry if someone tried to restart
 		 * task_work while we were executing it.
 		 */
-		v &= IO_POLL_REF_MASK;
 	} while (atomic_sub_return(v, &req->poll_refs) & IO_POLL_REF_MASK);
 
 	io_napi_add(req);

--
2.43.0

From: Jens Axboe <[email protected]>

[ Upstream commit a68ed2df72131447d131531a08fe4dfcf4fa4653 ]

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.

Backport notes for linux-6.6.y:
- In 6.6.y the do-while masks v in the while-condition itself

    (`atomic_sub_return(v & IO_POLL_REF_MASK, ...) & IO_POLL_REF_MASK`),
    so v can carry IO_POLL_RETRY_FLAG / IO_POLL_CANCEL_FLAG bits when
    we reach the multishot branch.  The HUP check therefore compares
    `(v & IO_POLL_REF_MASK) != 1` rather than the upstream
    `v != 1`, to avoid reacting to flag bits.

- io_poll_issue takes ts (struct io_tw_state *) here.

CVE: CVE-2026-23473

---
 io_uring/poll.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

@@ -321,7 +321,13 @@ static int io_poll_check_events(struct io_kiocb *req, struct io_tw_state *ts)
 				return IOU_POLL_REMOVE_POLL_USE_RES;
 			}
 		} else {
-			int ret = io_poll_issue(req, ts);
+			int ret;
+
+			/* multiple refs and HUP, ensure we loop once more */
+			if ((req->cqe.res & (POLLHUP | POLLRDHUP)) &&
+			    (v & IO_POLL_REF_MASK) != 1)
+				v--;
+			ret = io_poll_issue(req, ts);
 			if (ret == IOU_STOP_MULTISHOT)
 				return IOU_POLL_REMOVE_POLL_USE_RES;
 			else if (ret == IOU_REQUEUE)

--
2.43.0

From: Jens Axboe <[email protected]>

[ Upstream commit a68ed2df72131447d131531a08fe4dfcf4fa4653 ]

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.

Backport notes for linux-6.1.y:
- In 6.1.y the do-while masks v in the while-condition itself, so v can carry IO_POLL_RETRY_FLAG/IO_POLL_CANCEL_FLAG bits when we reach the multishot branch. The HUP check therefore compares (v & IO_POLL_REF_MASK) != 1 rather than the upstream v != 1.
- io_poll_issue takes bool *locked here (renamed to ts in 6.6+).
- 6.1.y has no IOU_REQUEUE return path; only IOU_STOP_MULTISHOT.

CVE: CVE-2026-23473

---
 io_uring/poll.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

@@ -303,7 +303,13 @@ static int io_poll_check_events(struct io_kiocb *req, bool *locked)
 				return IOU_POLL_REMOVE_POLL_USE_RES;
 			}
 		} else {
-			int ret = io_poll_issue(req, locked);
+			int ret;
+
+			/* multiple refs and HUP, ensure we loop once more */
+			if ((req->cqe.res & (POLLHUP | POLLRDHUP)) &&
+			    (v & IO_POLL_REF_MASK) != 1)
+				v--;
+			ret = io_poll_issue(req, locked);
 			io_kbuf_recycle(req, 0);
 
 			if (ret == IOU_STOP_MULTISHOT)

--
2.43.0

From: Jens Axboe <[email protected]>

[ Upstream commit 1967f0b1cafdde37aa9e08e6021c14bcc484b7a5 ]

Commit aacf2f9f382c ("io_uring: fix req->apoll_events") addressed synchronization issues between poll->events and req->apoll_events. However, a subsequent commit failed to maintain this consistency in the EPOLL_URING_WAKE code path.

The patch ensures that when EPOLLONESHOT is set during regular EPOLL_URING_WAKE handling, it's applied to both poll->events and req->apoll_events. This prevents a condition where "IORING_CQE_F_MORE is set in the previous CQE, while no more CQEs will be generated for this request."

Backport notes:
This patch applies cleanly and identically to linux-6.18.y, linux-6.12.y, linux-6.6.y, and linux-6.1.y. The io_poll_wake() EPOLL_URING_WAKE branch is byte-identical to the upstream pre-patch state across all four trees.

---
 io_uring/poll.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

@@ -417,8 +417,10 @@ static int io_poll_wake(struct wait_queue_entry *wait, unsigned mode, int sync,
 		 * disable multishot as there is a circular dependency between
 		 * CQ posting and triggering the event.
 		 */
-		if (mask & EPOLL_URING_WAKE)
+		if (mask & EPOLL_URING_WAKE) {
 			poll->events |= EPOLLONESHOT;
+			req->apoll_events |= EPOLLONESHOT;
+		}
 
 		/* optional, saves extra locking for removal in tw handler */
 		if (mask && poll->events & EPOLLONESHOT) {

--
2.43.0

OK with me, thanks.

Jens Axboe

First of all, I'm fine backporting these. But:

How on earth is this a CVE?! That's bogus. Yes it violates application expectations, it'll wait on a CQE it won't get, potentially. But this is the only side effect. That is NOT a CVE. Greg, please retract that.

Jens Axboe

The CVE is now rejected.

thanks,

greg k-h

Thanks.

Jens Axboe

Queued for all three branches. Thanks!

--
Thanks,
Sasha