linux-kernel - potential null pointer deference (or maybe invalid null check) in io_uring io_poll_remove

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <fe70c532-e2a7-3722-58a1-0fa4e5c5ff2c@canonical.com>
Date:   Fri, 9 Jul 2021 12:55:16 +0100
From:   Colin Ian King <colin.king@...onical.com>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     Pavel Begunkov <asml.silence@...il.com>, io-uring@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: potential null pointer deference (or maybe invalid null check) in
 io_uring io_poll_remove_double()

Hi Jens,

I was triaging some outstanding Coverity static analysis warnings and
found a potential issue in the following commit:

commit 807abcb0883439af5ead73f3308310453b97b624
Author: Jens Axboe <axboe@...nel.dk>
Date:   Fri Jul 17 17:09:27 2020 -0600

    io_uring: ensure double poll additions work with both request types

The analysis from Coverity is as follows:

4962 static int io_poll_double_wake(struct wait_queue_entry *wait,
unsigned mode,
4963                               int sync, void *key)
4964 {
4965        struct io_kiocb *req = wait->private;
4966        struct io_poll_iocb *poll = io_poll_get_single(req);
4967        __poll_t mask = key_to_poll(key);
4968
4969        /* for instances that support it check for an event match
first: */

    deref_ptr: Directly dereferencing pointer poll.

4970        if (mask && !(mask & poll->events))
4971                return 0;
4972        if (!(poll->events & EPOLLONESHOT))
4973                return poll->wait.func(&poll->wait, mode, sync, key);
4974
4975        list_del_init(&wait->entry);
4976

  Dereference before null check (REVERSE_INULL)
  check_after_deref: Null-checking poll suggests that it may be null,
but it has already been dereferenced on all paths leading to the check.

4977        if (poll && poll->head) {
4978                bool done;

pointer poll is being dereferenced on line 4970, however, on line 4977
it is being null checked. Either the null check is redundant (because it
can never be null) or it needs to be performed before the poll->events
read on line 4970.

Colin