Re: [syzbot] KASAN: use-after-free Read in __usb_hcd_giveback_urb (2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06.12.22 16:38, Alan Stern wrote:

Hi,

Oliver:

This looks like a bug in the anchor API.

Yes, it does.
On Tue, Dec 06, 2022 at 02:43:41AM -0800, syzbot wrote:
Hello,

syzbot found the following issue on:

HEAD commit:    ef4d3ea40565 afs: Fix server->active leak in afs_put_server
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=100b244d880000
kernel config:  https://syzkaller.appspot.com/x/.config?x=8e7e79f8a1e34200
dashboard link: https://syzkaller.appspot.com/bug?extid=712fd0e60dda3ba34642
compiler:       Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/ef790e7777cd/disk-ef4d3ea4.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2ed3c6bc9230/vmlinux-ef4d3ea4.xz
kernel image: https://storage.googleapis.com/syzbot-assets/f1dbd004fa88/bzImage-ef4d3ea4.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+712fd0e60dda3ba34642@xxxxxxxxxxxxxxxxxxxxxxxxx

xpad 3-1:179.65: xpad_irq_in - usb_submit_urb failed with result -19
xpad 3-1:179.65: xpad_irq_out - usb_submit_urb failed with result -19
==================================================================
BUG: KASAN: use-after-free in register_lock_class+0x8d2/0x9b0 kernel/locking/lockdep.c:1338
Read of size 1 at addr ffff88807a58b091 by task kworker/u4:3/46

CPU: 0 PID: 46 Comm: kworker/u4:3 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: bat_events batadv_nc_worker
Call Trace:
  <IRQ>
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
  print_address_description+0x74/0x340 mm/kasan/report.c:284
  print_report+0x107/0x220 mm/kasan/report.c:395
  kasan_report+0x139/0x170 mm/kasan/report.c:495
  register_lock_class+0x8d2/0x9b0 kernel/locking/lockdep.c:1338
  __lock_acquire+0xe4/0x1f60 kernel/locking/lockdep.c:4934
  lock_acquire+0x1a7/0x400 kernel/locking/lockdep.c:5668
  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
  _raw_spin_lock_irqsave+0xd1/0x120 kernel/locking/spinlock.c:162
  __wake_up_common_lock kernel/sched/wait.c:136 [inline]
  __wake_up+0xf8/0x1c0 kernel/sched/wait.c:156
  __usb_hcd_giveback_urb+0x3a0/0x530 drivers/usb/core/hcd.c:1674


This is the call to usb_anchor_resume_wakeups().  The call is made after
the completion handler callback.  Evidently the xpad driver deallocated
the anchor during that time window.  This can happen if the driver is
just waiting for its last URB to complete before freeing all its memory.

Yes, complete() had run.

I don't know what the best solution is.  It may be necessary to refcount
anchors somehow.

Then we cannot embed them anymore. Many drivers would need a lot of changes.
xpad included.

As far as I can tell the order we decrease use_count is correct. But:

6ec4147e7bdbd (Hans de Goede             2013-10-09 17:01:41 +0200 1674)        usb_anchor_resume_wakeups(anchor);
94dfd7edfd5c9 (Ming Lei                  2013-07-03 22:53:07 +0800 1675)        atomic_dec(&urb->use_count);

Do we need to guarantee memory ordering here?

	Regards
		Oliver



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux