Re: invalid opcode in map_vdso

[Dmitry Vyukov]

On Wed, Sep 23, 2020 at 12:30 PM Borislav Petkov <bp@xxxxxxxxx> 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