CVE-2023-52903

In the Linux kernel, the following vulnerability has been resolved:

io_uring: lock overflowing for IOPOLL

syzbot reports an issue with overflow filling for IOPOLL:

WARNING: CPU: 0 PID: 28 at iouring/iouring.c:734 iocqringeventoverflow+0x1c0/0x230 iouring/iouring.c:734 CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0 Workqueue: eventsunbound ioringexitwork Call trace:  iocqringeventoverflow+0x1c0/0x230 iouring/iouring.c:734  ioreqcqeoverflow+0x5c/0x70 iouring/iouring.c:773  iofillcqereq iouring/iouring.h:168 [inline]  iodoiopoll+0x474/0x62c iouring/rw.c:1065  ioiopolltryreapevents+0x6c/0x108 iouring/iouring.c:1513  iouringtrycancelrequests+0x13c/0x258 iouring/iouring.c:3056  ioringexitwork+0xec/0x390 iouring/iouring.c:2869  processonework+0x2d8/0x504 kernel/workqueue.c:2289  workerthread+0x340/0x610 kernel/workqueue.c:2436  kthread+0x12c/0x158 kernel/kthread.c:376  retfrom_fork+0x10/0x20 arch/arm64/kernel/entry.S:863

There is no real problem for normal IOPOLL as flush is also called with uring_lock taken, but it's getting more complicated for IOPOLL|SQPOLL, for which _iocqringoverflowflush() happens from the CQ waiting path.