public inbox for [email protected]
 help / color / mirror / Atom feed
From: chase xd <[email protected]>
To: Jens Axboe <[email protected]>,
	Pavel Begunkov <[email protected]>,
	[email protected],  [email protected]
Subject: Re: Potiential nullptr derefence in io_do_iopoll
Date: Sun, 10 Nov 2024 14:31:38 +0100	[thread overview]
Message-ID: <CADZouDSZj_V9HBuzXkDqHZZEaG8d++z3knxYAnvbrOTbZAgs5g@mail.gmail.com> (raw)
In-Reply-To: <CADZouDQJOe-JimRj8f4ELtKOzHFiz7yDqnqcpSMP8oU=RuypGQ@mail.gmail.com>

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 <[email protected]> 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

      reply	other threads:[~2024-11-10 13:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-10 13:24 Potiential nullptr derefence in io_do_iopoll chase xd
2024-11-10 13:31 ` chase xd [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADZouDSZj_V9HBuzXkDqHZZEaG8d++z3knxYAnvbrOTbZAgs5g@mail.gmail.com \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox