Sorry, apparently I missed a check [here](https://elixir.bootlin.com/linux/v6.9/source/io_uring/uring_cmd.c#L169). this is not legit then. On Sun, Nov 10, 2024 at 2:24 PM chase xd <sl1589472800@xxxxxxxxx> wrote: > > Dear maintainers, > > I'm looking into io_uring internals and find there might be a bug in > io_do_iopoll, but I'm struggling to construct a POC due to my lack of > knowledge about the kernel internals. So maybe it's better to put it > here for discussion. > > After [issuing an > SQE](https://elixir.bootlin.com/linux/v6.9/source/io_uring/io_uring.c#L1920) > in iopoll-enabled io_uring, if the return value is > `IOU_ISSUE_SKIP_COMPLETE` and the op supports `iopoll_queue`, the req > will be added to `ctx->iopoll_list` and later retrieved in > `io_do_iopoll`, where `iopoll` or `uring_cmd_iopoll` of the req file > op is [called](https://elixir.bootlin.com/linux/v6.9/source/io_uring/rw.c#L1167). > > IMHO here we miss a check of whether `iopoll` or `uring_cmd_iopoll` is > implemented. A more understandable case for me is, the custom ioctl > function with [IORING_OP_URING_CMD](https://elixir.bootlin.com/linux/v6.11.7/source/io_uring/opdef.c#L416) > satisfies all the constraints and will go to this path if `uring_cmd` > returns `-EIOCBQUEUED` > [here](https://elixir.bootlin.com/linux/v6.9/source/io_uring/uring_cmd.c#L192). > > So this requires that all the ops with `->uring_cmd` returning > `-EIOCBQUEUED` should support `->uring_cmd_iopoll` as well, which is > not the case for > [ublk_ch_fops](https://elixir.bootlin.com/linux/v6.9/source/drivers/block/ublk_drv.c#L1967) > resulting in a nullptr-deref in `io_do_poll`. I'm wondering if this is > legit. > > Note that the related code changes a bit for [newer > kernel](https://elixir.bootlin.com/linux/v6.11/source/io_uring/uring_cmd.c#L261). > > Best Regards
