Re: Syzkaller found a bug: KASAN: null-ptr-deref Write in prepare_to_wait

From: Waiman Long
Date: Thu Nov 17 2022 - 18:53:38 EST


On 11/17/22 17:17, Sanan Hasanov wrote:
Good day, dear maintainers,

We found a bug using a modified kernel configuration file used by syzbot.

We enhanced the coverage of the configuration file using our tool, klocalizer.

Kernel branch: linux-next 5.11.0+ (HEAD detached at 8310b77b48c5)

config file and c reproducer are attached.

Thank you!

==================================================================
BUG: KASAN: null-ptr-deref in instrument_atomic_read_write include/linux/instrumented.h:101 [inline]
BUG: KASAN: null-ptr-deref in atomic_try_cmpxchg_acquire include/asm-generic/atomic-instrumented.h:705 [inline]
BUG: KASAN: null-ptr-deref in queued_spin_lock include/asm-generic/qspinlock.h:82 [inline]
BUG: KASAN: null-ptr-deref in do_raw_spin_lock_flags include/linux/spinlock.h:195 [inline]
BUG: KASAN: null-ptr-deref in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:119 [inline]
BUG: KASAN: null-ptr-deref in _raw_spin_lock_irqsave+0x6c/0xd0 kernel/locking/spinlock.c:159
Write of size 4 at addr 0000000000000010 by task syz-executor.3/1879

CPU: 1 PID: 1879 Comm: syz-executor.3 Not tainted 5.11.0+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0xb0/0xf3 lib/dump_stack.c:120
__kasan_report mm/kasan/report.c:400 [inline]
kasan_report.cold+0x10c/0x10e mm/kasan/report.c:413
check_memory_region_inline mm/kasan/generic.c:179 [inline]
check_memory_region+0x17c/0x1e0 mm/kasan/generic.c:185
instrument_atomic_read_write include/linux/instrumented.h:101 [inline]
atomic_try_cmpxchg_acquire include/asm-generic/atomic-instrumented.h:705 [inline]
queued_spin_lock include/asm-generic/qspinlock.h:82 [inline]
do_raw_spin_lock_flags include/linux/spinlock.h:195 [inline]
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:119 [inline]
_raw_spin_lock_irqsave+0x6c/0xd0 kernel/locking/spinlock.c:159
prepare_to_wait+0x79/0x3c0 kernel/sched/wait.c:259
io_uring_cancel_files fs/io_uring.c:9014 [inline]
io_uring_cancel_task_requests+0x986/0xfa0 fs/io_uring.c:9054
io_uring_flush+0x311/0x470 fs/io_uring.c:9236
filp_close+0xad/0x150 fs/open.c:1286
close_files fs/file.c:403 [inline]
put_files_struct fs/file.c:418 [inline]
put_files_struct+0x193/0x280 fs/file.c:415
exit_files+0xa4/0xd0 fs/file.c:435
do_exit+0xa35/0x27d0 kernel/exit.c:820
do_group_exit+0xee/0x310 kernel/exit.c:922
get_signal+0x3b5/0x1a60 kernel/signal.c:2773
arch_do_signal_or_restart+0x2eb/0x18e0 arch/x86/kernel/signal.c:811
handle_signal_work kernel/entry/common.c:147 [inline]
exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
exit_to_user_mode_prepare+0xba/0x130 kernel/entry/common.c:208
__syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline]
syscall_exit_to_user_mode+0x1d/0x40 kernel/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f06219f6dcd
Code: Unable to access opcode bytes at RIP 0x7f06219f6da3.
RSP: 002b:00007f0620b66c98 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 00007f0621b23f80 RCX: 00007f06219f6dcd
RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007f0621b23f88
RBP: 00007f0621b23f88 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f0621b23f8c
R13: 00007ffcf7101edf R14: 00007ffcf7102080 R15: 00007f0620b66d80
==================================================================
BUG: kernel NULL pointer dereference, address: 0000000000000010
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] SMP KASAN NOPTI

According to this kernel splat, the spinlock address is at 0x10.

253 void
254 prepare_to_wait(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry, int state)
255 {
256         unsigned long flags;
257
258         wq_entry->flags &= ~WQ_FLAG_EXCLUSIVE;
259         spin_lock_irqsave(&wq_head->lock, flags);
260         if (list_empty(&wq_entry->entry))
261                 __add_wait_queue(wq_head, wq_entry);
262         set_current_state(state);
263         spin_unlock_irqrestore(&wq_head->lock, flags);
264 }
265 EXPORT_SYMBOL(prepare_to_wait);

The first element of wait_queue_head structure is a spinlock. That means wq_head has a value of 0x10 too. Since it is called by io_uring_cancel_files(), I think the bug is in the io_uring code as it passed the wrong value to prepare_to_wait(). I didn't try to go further as I am not that familiar with the io_uring code.

Cheers,
Longman