[syzbot] unexpected kernel reboot (8)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 1707c39ae309 Merge tag 'driver-core-6.0-rc7' of git://git...
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=17324288880000
kernel config: https://syzkaller.appspot.com/x/.config?x=122d7bd4fc8e0ecb
dashboard link: https://syzkaller.appspot.com/bug?extid=8346a1aeed52cb04c9ba
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15ca1f54880000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=155622df080000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8346a1...@syzkaller.appspotmail.com

fuseblk: Unknown parameter ' Decompressing Linux... Parsing ELF... done. Booting the kernel. Decompressing Linux... Parsing ELF... done. Booting the kernel.


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

[Dmitry Vyukov]

On Wed, 28 Sept 2022 at 04:03, syzbot

<syzbot+8346a1...@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 1707c39ae309 Merge tag 'driver-core-6.0-rc7' of git://git...
> git tree: upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=17324288880000
> kernel config: https://syzkaller.appspot.com/x/.config?x=122d7bd4fc8e0ecb
> dashboard link: https://syzkaller.appspot.com/bug?extid=8346a1aeed52cb04c9ba
> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15ca1f54880000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=155622df080000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+8346a1...@syzkaller.appspotmail.com
>
> fuseblk: Unknown parameter ' Decompressing Linux... Parsing ELF... done. Booting the kernel. Decompressing Linux... Parsing ELF... done. Booting the kernel.

+fuse maintainers

This one is somewhat funny. The fuzzer tricked the kernel into
printing the rebooting message via normal logging. So on the console
it looks like the kernel started rebooting.

But it looks like the kernel is reading/printing something it
shouldn't. The reproducer doesn't pass the "Decompressing Linux"
string in mount options. So the kernel is reading random memory
out-of-bounds? a non-0-terminated string somewhere?

[Tetsuo Handa]

This is not a kernel bug but a fuzzer's bug.

Looking at https://syzkaller.appspot.com/text?tag=ReproC&x=155622df080000 ,
this reproducer is reading data from /dev/vcs to [0x20001dc0,0x20003DE0) range,
and passing subset of this range [0x20002300,0x20003300) as "const void *data"
argument of mount() syscall which is interpreted as a string.

That is, this problem happens when console screen buffer by chance contained
kernel messages which the kernel has printk()ed upon boot.

(I defer "#syz invalid" because we need to somehow fix this problem on the fuzzer side.)

[Dmitry Vyukov]

On Thu, 29 Sept 2022 at 12:25, Tetsuo Handa

<penguin...@i-love.sakura.ne.jp> wrote:
>
> This is not a kernel bug but a fuzzer's bug.
>
> Looking at https://syzkaller.appspot.com/text?tag=ReproC&x=155622df080000 ,
> this reproducer is reading data from /dev/vcs to [0x20001dc0,0x20003DE0) range,
> and passing subset of this range [0x20002300,0x20003300) as "const void *data"
> argument of mount() syscall which is interpreted as a string.
>
> That is, this problem happens when console screen buffer by chance contained
> kernel messages which the kernel has printk()ed upon boot.
>
> (I defer "#syz invalid" because we need to somehow fix this problem on the fuzzer side.)

Oh, I see, I missed the read from /dev/vcs. Thanks for looking into it.
Thinking of possible solutions I think the easiest thing is to
stricten matching of the reboot message, e.g. require it to start from
the beginning of the line, don't have anything at the end, etc. The
real message should not be subject to any "corruptions".

+Aleksandr, please take care of this.

Not sure if there should be a policy on printing user-provided strings
to dmesg in general or not. Unpriv fs types like tmpfs/fuse
effectively allow the injection of arbitrary messages into dmesg w/o
the permission.

[syzbot]

syzbot suspects this issue was fixed by commit:

commit 7734a0f31e99c433df3063bbb7e8ee5a16a2cb82
Author: Alexander Lobakin <alexandr...@intel.com>
Date: Mon Jan 9 17:04:02 2023 +0000

x86/boot: Robustify calling startup_{32,64}() from the decompressor code

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14606624c80000
start commit: 1fe4fd6f5cad Merge tag 'xfs-6.2-fixes-2' of git://git.kern..
git tree: upstream
kernel config: https://syzkaller.appspot.com/x/.config?x=edc860b1c9b6751
dashboard link: https://syzkaller.appspot.com/bug?extid=8346a1aeed52cb04c9ba
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12baac4a480000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=118bf42c480000

If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: x86/boot: Robustify calling startup_{32,64}() from the decompressor code

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

[syzbot]

Auto-closing this bug as obsolete.
No recent activity, existing reproducers are no longer triggering the issue.