linux-kernel - Re: WARNING in refcount_sub_and

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

Date:   Fri, 27 Oct 2017 00:56:18 +0800
From:   Xin Long <lucien.xin@...il.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     ChunYu Wang <chunwang@...hat.com>,
        syzbot 
        <bot+a004c8dcbae7c160bf1bbd6e6af2e9cf4fa54f84@...kaller.appspotmail.com>,
        David Miller <davem@...emloft.net>,
        LKML <linux-kernel@...r.kernel.org>, linux-sctp@...r.kernel.org,
        netdev <netdev@...r.kernel.org>,
        Neil Horman <nhorman@...driver.com>,
        syzkaller-bugs@...glegroups.com,
        Vladislav Yasevich <vyasevich@...il.com>
Subject: Re: WARNING in refcount_sub_and_test

On Fri, Oct 27, 2017 at 12:13 AM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
> On Thu, Oct 26, 2017 at 5:49 PM, Xin Long <lucien.xin@...il.com> wrote:
>> On Thu, Oct 26, 2017 at 10:49 PM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>>> On Thu, Oct 26, 2017 at 10:53 AM, ChunYu Wang <chunwang@...hat.com> wrote:
>>>> Hi all,
>>>>
>>>> I am failed to reproduce it on target kernel with the reproducer file
>>>> or replaying the target syzkaller description log file, do I made
>>>> something wrong or there exists more subjects then the line in
>>>> repro.txt:
>>>>
>>>> #{Threaded:true Collide:true Repeat:false Procs:1 Sandbox:namespace
>>>> Fault:false FaultCall:-1 FaultNth:0 EnableTun:false UseTmpDir:true
>>>> HandleSegv:false WaitRepeat:false Debug:false Repro:false}
>>>
>>>
>>> Hi ChunYu,
>>>
>>> I've just re-tested the C repro and was able to trigger the bug in a second.
>>> I've checked out 49ca1943a7adb429b11b8e05d81bc821694b76c7, copied the
>>> provided config, run make olddefconfig, built with gcc-7 (you can get
>>> the exact one here
>>> https://storage.googleapis.com/syzkaller/gcc-7.tar.gz). Then run in
>>> qemu (most of the flags are probably irrelevant):
>>>
>>> qemu-system-x86_64 -hda wheezy.img -net
>>> user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic -nographic -kernel
>>> arch/x86/boot/bzImage -append "kvm-intel.nested=1
>>> kvm-intel.unrestricted_guest=1 kvm-intel.ept=1
>>> kvm-intel.flexpriority=1 kvm-intel.vpid=1
>>> kvm-intel.emulate_invalid_guest_state=1 kvm-intel.eptad=1
>>> kvm-intel.enable_shadow_vmcs=1 kvm-intel.pml=1
>>> kvm-intel.enable_apicv=1 console=ttyS0 root=/dev/sda
>>> earlyprintk=serial slub_debug=UZ vsyscall=native rodata=n oops=panic
>>> panic_on_warn=1 panic=86400" -enable-kvm -pidfile vm_pid -m 2G -smp 4
>>> -cpu host -usb -usbdevice mouse -usbdevice tablet -soundhw all
>> Just wondering where we can get wheezy.img, if I can't download
>> somewhere, can you provide one if possible ?
>>
>> I made some imgs before, with kernel built with the .config mail-list
>> usually gave, the guest always failed to boot.
>
> Makes sense. Added image/key links here:
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
>
> Here are commands to start qemu, ssh into the VM. This just worked for
> me to reproduce the crash.
>
> qemu-system-x86_64 -hda wheezy.img -net
> user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic -nographic -kernel
> arch/x86/boot/bzImage -append "kvm-intel.nested=1
> kvm-intel.unrestricted_guest=1 kvm-intel.ept=1
> kvm-intel.flexpriority=1 kvm-intel.vpid=1
> kvm-intel.emulate_invalid_guest_state=1 kvm-intel.eptad=1
> kvm-intel.enable_shadow_vmcs=1 kvm-intel.pml=1
> kvm-intel.enable_apicv=1 console=ttyS0 root=/dev/sda
> earlyprintk=serial vsyscall=native rodata=n oops=panic panic_on_warn=1
> panic=86400" -enable-kvm -m 2G -smp 4 -cpu host -usb -usbdevice mouse
> -usbdevice tablet -soundhw all
>
> ssh -i wheezy.img.key -p 10022 -o UserKnownHostsFile=/dev/null -o
> StrictHostKeyChecking=no -o IdentitiesOnly=yes root@...alhost
Works, and be able to reproduce the issue. Thanks Dmitry.

Another thing is (you might also notice):
https://paste.fedoraproject.org/paste/N~htmOMPUSiIXGUeLH7yIw
This call trace always comes up after kernel has started.