On Fri, Sep 20, 2019 at 11:28:22AM +0200, Dmitry Vyukov wrote:

On Fri, Sep 20, 2019 at 11:21 AM Johan Hovold [off-list ref] wrote:

quoted

On Fri, Sep 20, 2019 at 11:13:14AM +0200, Dmitry Vyukov wrote:

quoted

On Fri, Sep 20, 2019 at 11:08 AM Johan Hovold [off-list ref] wrote:

quoted

On Fri, Aug 09, 2019 at 01:24:04PM -0700, syzbot wrote:

quoted

syzbot has found a reproducer for the following crash on:

HEAD commit:    e96407b4 usb-fuzzer: main usb gadget fuzzer driver
git tree:       https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=13871a4a600000
kernel config:  https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
dashboard link: https://syzkaller.appspot.com/bug?extid=0243cb250a51eeefb8cc
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11c4c8e2600000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11d80d2c600000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0243cb250a51eeefb8cc@syzkaller.appspotmail.com

usb 1-1: USB disconnect, device number 4
==================================================================
BUG: KASAN: use-after-free in atomic64_read
include/asm-generic/atomic-instrumented.h:836 [inline]
BUG: KASAN: use-after-free in atomic_long_read
include/asm-generic/atomic-long.h:28 [inline]
BUG: KASAN: use-after-free in __mutex_unlock_slowpath+0x96/0x670
kernel/locking/mutex.c:1211
Read of size 8 at addr ffff8881d1d0aa00 by task kworker/0:1/12

Let's resend and retest with commit id from latest report to make sure
the patch was actually applied during the last run:

The reply contains:
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1440268d600000
that's what's being parsed and applied during testing.

Thanks for confirming, but I can't seem to find that link in the report
from syzbot:

        https://lkml.kernel.org/r/000000000000b05ce40592f8521a@google.com

Is it supposed to be there?

I meant the previous one:
https://lore.kernel.org/linux-usb/000000000000d290e00592e5c17d@google.com/ (local)

The one that you pointed to indeed does not have a patch (was tested
without any patches). But you did not include any in the request, so
this WAI.

Ok, that was what I thought. I first tried retriggering the test by
responding to the mail with the patch and a new test directive, but when
that test failed, I figured the patch had not been applied and that I
had to include it directly in the mail when retesting.

Apparently misremembered someone from google responding to a patch with
a test directive, but perhaps they also included the patch in that mail.

Johan