mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2026-07-08 18:13:59 +02:00
Jens Axboe
35f1eb2e98
[ Upstream commita68ed2df72] 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 Cc: stable@vger.kernel.org # 6.12.y Fixes:dbc2564cfe("io_uring: let fast poll support multishot") Reported-by: Francis Brosseau <francis@malagauche.com> Link: https://github.com/axboe/liburing/issues/1549 Signed-off-by: Jens Axboe <axboe@kernel.dk> [backport for linux-6.12.y, verified 2026-05-01] Signed-off-by: Sasha Levin <sashal@kernel.org>