linux-kernel - 回复：KASAN: null-ptr-deref Write in tctx_task_work

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

Message-ID: <922a9ee9-9da6-4219-9e96-fe7d7198c0b6.bugreport@ubisectech.com>
Date: Mon, 18 Mar 2024 14:35:25 +0800
From: "Ubisectech Sirius" <bugreport@...sectech.com>
To: "Jens Axboe" <axboe@...nel.dk>,
  "linux-kernel" <linux-kernel@...r.kernel.org>,
  "linux-trace-kernel" <linux-trace-kernel@...r.kernel.org>
Subject: 回复：KASAN: null-ptr-deref Write in tctx_task_work_run

> I think you snipped the fault injection that came before this. It looks
> like an allocation failure, so we don't get tsk->io_uring setup for the
> SQPOLL thread. Not a great way to handle this, but can you try the
> below? Would be nicer if we could just prune the task rather than wake
> it and have it error.

Hi.
  The issue does not appear again when I apply the patch to the Linux kernel.


On 3/17/24 6:59 PM, Ubisectech Sirius wrote:
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.8.0-ge5e038b7ae9d. Attached to the email were a POC file of the issue.
> 
> Stack dump:
> 
> ==================================================================
> BUG: KASAN: null-ptr-deref in instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
> BUG: KASAN: null-ptr-deref in llist_del_all include/linux/llist.h:266 [inline]
> BUG: KASAN: null-ptr-deref in tctx_task_work_run+0x7d/0x330 io_uring/io_uring.c:1267
> Write of size 8 at addr 00000000000001c0 by task iou-sqp-215603/215604
> 
> CPU: 0 PID: 215604 Comm: iou-sqp-215603 Not tainted 6.8.0-ge5e038b7ae9d #40
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:88 [inline]
>  dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:114
>  kasan_report+0xbd/0xf0 mm/kasan/report.c:601
>  check_region_inline mm/kasan/generic.c:183 [inline]
>  kasan_check_range+0xf4/0x1a0 mm/kasan/generic.c:189
>  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
>  llist_del_all include/linux/llist.h:266 [inline]
>  tctx_task_work_run+0x7d/0x330 io_uring/io_uring.c:1267
>  io_sq_tw+0x12a/0x1d0 io_uring/sqpoll.c:245
>  io_sq_thread+0x8d7/0x18a0 io_uring/sqpoll.c:308
>  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
>  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
>  </TASK>
> ==================================================================
> Kernel panic - not syncing: KASAN: panic_on_warn set ...
> CPU: 0 PID: 215604 Comm: iou-sqp-215603 Not tainted 6.8.0-ge5e038b7ae9d #40
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014

I think you snipped the fault injection that came before this. It looks
like an allocation failure, so we don't get tsk->io_uring setup for the
SQPOLL thread. Not a great way to handle this, but can you try the
below? Would be nicer if we could just prune the task rather than wake
it and have it error.

diff --git a/io_uring/sqpoll.c b/io_uring/sqpoll.c
index 363052b4ea76..db7b0fdfe1cb 100644
--- a/io_uring/sqpoll.c
+++ b/io_uring/sqpoll.c
@@ -274,6 +274,10 @@ static int io_sq_thread(void *data)
  char buf[TASK_COMM_LEN];
  DEFINE_WAIT(wait);
 
+ /* offload context creation failed, just exit */
+ if (!current->io_uring) {
+  goto err_out;
+
  snprintf(buf, sizeof(buf), "iou-sqp-%d", sqd->task_pid);
  set_task_comm(current, buf);
 
@@ -371,7 +375,7 @@ static int io_sq_thread(void *data)
   atomic_or(IORING_SQ_NEED_WAKEUP, &ctx->rings->sq_flags);
  io_run_task_work();
  mutex_unlock(&sqd->lock);
-
+err_out:
  complete(&sqd->exited);
  do_exit(0);
 }

-- 
Jens Axboe