CVE-2023-52903

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: lock overflowing for IOPOLL<br /> <br /> syzbot reports an issue with overflow filling for IOPOLL:<br /> <br /> WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734<br /> CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0<br /> Workqueue: events_unbound io_ring_exit_work<br /> Call trace:<br />  io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734<br />  io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773<br />  io_fill_cqe_req io_uring/io_uring.h:168 [inline]<br />  io_do_iopoll+0x474/0x62c io_uring/rw.c:1065<br />  io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513<br />  io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056<br />  io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869<br />  process_one_work+0x2d8/0x504 kernel/workqueue.c:2289<br />  worker_thread+0x340/0x610 kernel/workqueue.c:2436<br />  kthread+0x12c/0x158 kernel/kthread.c:376<br />  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863<br /> <br /> There is no real problem for normal IOPOLL as flush is also called with<br /> uring_lock taken, but it&amp;#39;s getting more complicated for IOPOLL|SQPOLL,<br /> for which __io_cqring_overflow_flush() happens from the CQ waiting path.