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

[Waiman Long <longman@redhat.com>]

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