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]

Message-ID: <CACT4Y+aEkksuWQ3YPUfjZaSoWq01LxpkkdrLO83s7H50+0Lj5g@mail.gmail.com>
Date:   Fri, 27 Oct 2017 08:09:20 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Xin Long <lucien.xin@...il.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 Thu, Oct 26, 2017 at 6:56 PM, Xin Long <lucien.xin@...il.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.

Great!

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

Yes, I've noticed this one. It seems to happen on a first incoming
network connection (ssh/scp). I have not seen it before.