Re: [bug report] BUG: KASAN: out-of-bounds in io_req_local_work_add+0x3b1/0x4a0

[Pavel Begunkov <asml.silence@gmail.com>]

On 6/23/23 06:51, Guangwu Zhang wrote:
> Just hit the bug one time with liburing testing, so it hard to said
> which case triggered the issue,
> here is the test steps
> 1) enable kernel KASAN module
> 2) mkfs and mount with sda and set TEST_FILES=/dev/sda
> 3) copy all liburing cases to mount point
> 4) make runtests as root

Fwiw, I suspect it's a false positive warning due to
kasan checks we added in io_uring. Guangwu, can you decode
the trace? It should help to confirm whether the assumption
is right.

You can use scripts/decode_stacktrace.sh + specify what
source file was used.

Or do it with gdb like below by replacing "0x3b1" with
accordance with the warning message.

gdb vmlinux --ex "l io_req_local_work_add+0x3b1"


TL;DR;

static void io_req_local_work_add(struct io_kiocb *req)
{
	first = READ_ONCE(ctx->work_llist.first);
	do {
		if (first)
			nr_tw_prev = READ_ONCE(first->nr_tw);
		...
		req->io_task_work.node.next = first;
	} while (!try_cmpxchg(&ctx->work_llist, &first, req));
}

This might poke into a "freed" request, but we won't actually
use the value as the following cmpxchg will fail. It should
be fine to look into it because we're under rcu read lock
and requests are allocated with SLAB_TYPESAFE_BY_RCU.
The problem here is that it's not only kasan'ed on kfree,
but there are io_uring caches that are kasan'ed as well.


-- 
Pavel Begunkov