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 uringlock taken, but it's getting more complicated for IOPOLL|SQPOLL, for which _iocqringoverflow_flush() happens from the CQ waiting path.