linux-kernel - Re: general protection fault in do_move

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+ZN8CZq7L1GQANr25extEqPASRERGVh+sD4-55cvWPOSg@mail.gmail.com>
Date:   Mon, 24 Jun 2019 11:28:18 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     syzbot <syzbot+6004acbaa1893ad013f0@...kaller.appspotmail.com>,
        Arnd Bergmann <arnd@...db.de>, Jens Axboe <axboe@...nel.dk>,
        Borislav Petkov <bp@...en8.de>,
        Catalin Marinas <catalin.marinas@....com>,
        Christian Brauner <christian@...uner.io>,
        David Howells <dhowells@...hat.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Hannes Reinecke <hare@...e.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: general protection fault in do_move_mount (2)

On Tue, Jun 18, 2019 at 4:03 PM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Tue, Jun 18, 2019 at 03:47:10AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:    9e0babf2 Linux 5.2-rc5
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=138b310aa00000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=d16883d6c7f0d717
> > dashboard link: https://syzkaller.appspot.com/bug?extid=6004acbaa1893ad013f0
> > compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=154e8c2aa00000
>
> IDGI...
>
> mkdir(&(0x7f0000632000)='./file0\x00', 0x0)
> mount(0x0, 0x0, 0x0, 0x0, 0x0)
> syz_open_procfs(0x0, 0x0)
> r0 = open(&(0x7f0000032ff8)='./file0\x00', 0x0, 0x0)
> r1 = memfd_create(&(0x7f00000001c0)='\xb3', 0x0)
> write$FUSE_DIRENT(r1, &(0x7f0000000080)=ANY=[], 0x29)
> move_mount(r0, &(0x7f0000000040)='./file0\x00', 0xffffffffffffff9c, &(0x7f0000000100)='./file0\x00', 0x66)
>
> reads as if we'd done mkdir ./file0, opened it and then tried
> to feed move_mount(2) "./file0" relative to that descriptor.
> How the hell has that avoided an instant -ENOENT?  On the first
> pair, that is - the second one (AT_FDCWD, "./file0") is fine...
>
> Confused...  Incidentally, what the hell is
>         mount(0x0, 0x0, 0x0, 0x0, 0x0)
> about?  *IF* that really refers to mount(2) with
> such arguments, all you'll get is -EFAULT.  Way before
> it gets to actually doing anything - it won't get past
>         /* ... and get the mountpoint */
>         retval = user_path(dir_name, &path);
>         if (retval)
>                 return retval;
> in do_mount(2)...

Yes, mount(0x0, 0x0, 0x0, 0x0, 0x0) is mount with 0 arguments. Most
likely it returns EFAULT.
Since the reproducer have "threaded":true,"collide":true and no C
repro, most likely this is a subtle race. So it attempted to remove
mount(0x0, 0x0, 0x0, 0x0, 0x0) but it did not crash, so the conclusion
was that it's somehow needed. You can actually see that other
reproducers for this bug do not have this mount, but are otherwise
similar.

With "threaded":true,"collide":true the execution mode is not just
"execute each syscall once one after another".
The syscalls are executed in separate threads and actually twice. You
can see the approximate execution mode in this C program:
https://gist.githubusercontent.com/dvyukov/c3a52f012e7cff9bdebf3935d35245cf/raw/b5587824111a1d982c985b00137ae8609572335b/gistfile1.txt
Yet using the C program did not trigger the crash somehow (maybe just
slightly different timings).

Since syzkaller was able to reproduce it multiple times, it looks like
a real bug rather than an induced memory corruption or something.