linux-kernel - Re: invalid opcode in map

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

Date:   Fri, 25 Sep 2020 14:16:57 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     syzbot <syzbot+9cf5373b0e15476f39a2@...kaller.appspotmail.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        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>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: invalid opcode in map_vdso

On Wed, Sep 23, 2020 at 12:30 PM Borislav Petkov <bp@...en8.de> wrote:
>
> On Wed, Sep 23, 2020 at 11:19:40AM +0200, Dmitry Vyukov wrote:
> > +clang-built-linux
> > Looks like another one with kernel code overwrite in clang build.
>
> Uuh, that's a nice and refreshing one - the pattern is not zeroes this
> time
>
> Code: 16 48 89 ef 48 8b 34 24 31 c9 e8 88 7c a7 00 eb 7a 4c 8b 74 24 28 43 80 3c 3e 00 48 8b 5c 24 08 74 08 4c 89 ef e8 4d 77 70 70 <07> 20 05 00 00 49 03 6d 00 48 89 e8 48 c1 e8 03 42 80 3c 38 00 74
> All code
> ========
>    0:   16                      (bad)
>    1:   48 89 ef                mov    %rbp,%rdi
>    4:   48 8b 34 24             mov    (%rsp),%rsi
>    8:   31 c9                   xor    %ecx,%ecx
>    a:   e8 88 7c a7 00          callq  0xa77c97
>    f:   eb 7a                   jmp    0x8b
>   11:   4c 8b 74 24 28          mov    0x28(%rsp),%r14
>   16:   43 80 3c 3e 00          cmpb   $0x0,(%r14,%r15,1)
>   1b:   48 8b 5c 24 08          mov    0x8(%rsp),%rbx
>   20:   74 08                   je     0x2a
>   22:   4c 89 ef                mov    %r13,%rdi
>   25:   e8 4d 77 70 70          callq  0x70707777
>   2a:*  07                      (bad)           <-- trapping instruction
>   2b:   20 05 00 00 49 03       and    %al,0x3490000(%rip)        # 0x3490031
>   31:   6d                      insl   (%dx),%es:(%rdi)
>   32:   00 48 89                add    %cl,-0x77(%rax)
>   35:   e8 48 c1 e8 03          callq  0x3e8c182
>   3a:   42 80 3c 38 00          cmpb   $0x0,(%rax,%r15,1)
>   3f:   74                      .byte 0x74
>
> Code starting with the faulting instruction
> ===========================================
>    0:   07                      (bad)
>    1:   20 05 00 00 49 03       and    %al,0x3490000(%rip)        # 0x3490007
>    7:   6d                      insl   (%dx),%es:(%rdi)
>    8:   00 48 89                add    %cl,-0x77(%rax)
>    b:   e8 48 c1 e8 03          callq  0x3e8c158
>   10:   42 80 3c 38 00          cmpb   $0x0,(%rax,%r15,1)
>   15:   74                      .byte 0x74

There is strong indication that this is a manifestation of the same
problem we see in other crashes.
Let's make one canonical bug for this:

#syz dup: general protection fault in perf_misc_flags