linux-kernel - [PATCH] io-wq: Fix UAF when wakeup wqe in hash waitqueue

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>] [day] [month] [year] [list]

Message-Id: <20210524071844.24085-1-qiang.zhang@windriver.com>
Date:   Mon, 24 May 2021 15:18:44 +0800
From:   qiang.zhang@...driver.com
To:     axboe@...nel.dk, asml.silence@...il.com,
        syzbot+6cb11ade52aa17095297@...kaller.appspotmail.com
Cc:     io-uring@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH] io-wq: Fix UAF when wakeup wqe in hash waitqueue

From: Zqiang <qiang.zhang@...driver.com>

The syzbot report a UAF when iou-wrk accessing wqe of the hash
waitqueue. in the case of sharing a hash waitqueue between two
io-wq, when one of the io-wq is destroyed, all iou-wrk in this
io-wq are awakened, all wqe belonging to this io-wq are removed
from hash waitqueue, after that, all iou-wrk belonging to this
io-wq begin running, suppose following scenarios, wqe[0] and wqe[1]
belong to this io-wq, and these work has same hash value.

    CPU0	                                             CPU1
iou-wrk0(wqe[0])                                         iou-wrk1(wqe[1])

while test_bit IO_WQ_BIT_EXIT			while test_bit IO_WQ_BIT_EXIT
                                                   io_worker_handle_work
 schedule_timeout (sleep be break by wakeup         io_get_next_work
  and the IO_WQ_BIT_EXIT be set)                      set_bit hash

test_bit IO_WQ_BIT_EXIT (return true)
 wqe->work_list (is not empty)
  io_get_next_work
   io_wq_is_hashed
    test_and_set_bit hash (is true)		    (hash!=-1U&&!next_hashed) true
   (there is no work other than hash work)
    io_wait_on_hash                                 clear_bit hash
     spin_lock					     wq_has_sleeper (is false)
     list_empty(&wqe->wait.entry) (is true)
     __add_wait_queue				    (hash->wait is empty,not wakeup
						    and IO_WQ_BIT_EXIT has been set,
      ........					    the wqe->work_list is empty exit
   (there is no work other than hash work	    while loop)
	io_get_next_work will return NULL)
   return NULL					    (the wqe->work_list is empty
 						    the io_worker_handle_work is not
                                                    called)
io_worker_exit                                         io_worker_exit

In the above scenario, wqe may be mistakenly removing
opportunities from the queue, this leads to when the wqe is
released, it still in hash waitqueue. when a iou-wrk belonging
to another io-wq access hash waitqueue will trigger UAF,
To avoid this phenomenon, after all iou-wrk thread belonging to the
io-wq exit, remove wqe from the hash waiqueue, at this time,
there will be no operation to queue the wqe.

Reported-by: syzbot+6cb11ade52aa17095297@...kaller.appspotmail.com
Signed-off-by: Zqiang <qiang.zhang@...driver.com>
---
 fs/io-wq.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/fs/io-wq.c b/fs/io-wq.c
index 5361a9b4b47b..911a1274aabd 100644
--- a/fs/io-wq.c
+++ b/fs/io-wq.c
@@ -1003,13 +1003,16 @@ static void io_wq_exit_workers(struct io_wq *wq)
 		struct io_wqe *wqe = wq->wqes[node];
 
 		io_wq_for_each_worker(wqe, io_wq_worker_wake, NULL);
-		spin_lock_irq(&wq->hash->wait.lock);
-		list_del_init(&wq->wqes[node]->wait.entry);
-		spin_unlock_irq(&wq->hash->wait.lock);
 	}
 	rcu_read_unlock();
 	io_worker_ref_put(wq);
 	wait_for_completion(&wq->worker_done);
+
+	for_each_node(node) {
+		spin_lock_irq(&wq->hash->wait.lock);
+		list_del_init(&wq->wqes[node]->wait.entry);
+		spin_unlock_irq(&wq->hash->wait.lock);
+	}
 	put_task_struct(wq->task);
 	wq->task = NULL;
 }
-- 
2.17.1