linux-kernel - Re: unexpected kernel reboot (3)

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, 13 Jul 2018 14:58:11 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     syzbot <syzbot+cce9ef2dd25246f815ee@...kaller.appspotmail.com>
Cc:     adobriyan@...il.com, gs051095@...il.com, jhugo@...eaurora.org,
        jpoimboe@...hat.com, lauraa@...eaurora.org,
        linux-kernel@...r.kernel.org, linux@...inikbrodowski.net,
        mingo@...nel.org, rostedt@...dmis.org,
        syzkaller-bugs@...glegroups.com, tglx@...utronix.de,
        thomas.lendacky@....com
Subject: Re: unexpected kernel reboot (3)

On Fri, 13 Jul 2018 14:39:02 -0700 syzbot <syzbot+cce9ef2dd25246f815ee@...kaller.appspotmail.com> wrote:

> Hello,
> 
> syzbot found the following crash on:

hm, I don't think I've seen an "unexpected reboot" report before.

Can you expand on specifically what happened here?  Did the machine
simply magically reboot itself?  Or did an external monitor whack it,
or...

Does this test distinguish from a kernel which simply locks up?

> HEAD commit:    1e4b044d2251 Linux 4.18-rc4
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17c6a6d0400000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
> dashboard link: https://syzkaller.appspot.com/bug?extid=cce9ef2dd25246f815ee
> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=165012c2400000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1571462c400000

I assume the "C reproducer" is irrelevant here.

Is it reproducible?

> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+cce9ef2dd25246f815ee@...kaller.appspotmail.com
> 
> output_len: 0x00000000092459b0
> kernel_total_size: 0x000000000a505000
> trampoline_32bit: 0x000000000009d000
> 
> Decompressing Linux... Parsing ELF... done.
> Booting the kernel.
> [    0.000000] Linux version 4.18.0-rc4+ (syzkaller@ci) (gcc version 8.0.1  
> 20180413 (experimental) (GCC)) #138 SMP Mon Jul 9 10:45:11 UTC 2018
> [    0.000000] Command line: BOOT_IMAGE=/vmlinuz root=/dev/sda1  
> console=ttyS0 earlyprintk=serial vsyscall=native rodata=n  
> ftrace_dump_on_oops=orig_cpu oops=panic panic_on_warn=1 nmi_watchdog=panic  
> panic=86400 workqueue.watchdog_thresh=140 kvm-intel.nested=1  
>
> ...
>
> regulatory database
> [    4.519364] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
> [    4.520839] platform regulatory.0: Direct firmware load for  
> regulatory.db failed with error -2
> [    4.522155] cfg80211: failed to load regulatory.db
> [    4.522185] ALSA device list:
> [    4.523499]   #0: Dummy 1
> [    4.523951]   #1: Loopback 1
> [    4.524389]   #2: Virtual MIDI Card 1
> [    4.825991] input: ImExPS/2 Generic Explorer Mouse as  
> /devices/platform/i8042/serio1/input/input4
> [    4.829533] md: Waiting for all devices to be available before autodetect
> [    4.830562] md: If you don't use raid, use raid=noautodetect
> [    4.835237] md: Autodetecting RAID arrays.
> [    4.835882] md: autorun ...
> [    4.836364] md: ... autorun DONE.

Can we assume that the failure occurred in or immediately after the MD code,
or might some output have been truncated?

It would be useful to know what the kernel was initializing immediately
after MD.  Do you have a kernel log for the same config when the kerenl
didn't fail?  Or maybe enable initcall_debug?