Re: [tip:x86/asm] x86/asm/entry/64: Remove unused thread_struct::usersp

[Borislav Petkov <bp@alien8.de>]

[-- Attachment #1: Type: text/plain, Size: 4790 bytes --]

On Mon, Mar 16, 2015 at 11:20:38PM +0100, Denys Vlasenko wrote:
> What's your config?

Attached.

> What distro do you run in the guest?

Some old debian. Here's the full qemu command line:

$ qemu-system-x86_64
-enable-kvm
-gdb tcp::1234
-cpu Opteron_G5
-m 2048
-hda /home/boris/kvm/debian/sid-x86_64.img
-boot menu=off,order=c
-localtime
-net nic,model=rtl8139
-net user,hostfwd=tcp::1235-:22
-usbdevice tablet
-kernel /home/boris/kernel/linux-2.6/arch/x86/boot/bzImage
-append "root=/dev/sda1 debug ignore_loglevel log_buf_len=16M earlyprintk=ttyS0,115200 console=ttyS0,115200 console=tty0 "
-monitor pty
-virtfs local,path=/tmp,mount_tag=tmp,security_model=none
-serial file:/home/boris/kvm/test-x86_64-1235.log
-snapshot
-name "Debian x86_64:1235"
-smp 2

> Yep. This is one of those cases where "it must be completely safe"...

Yap.

> > [    5.285547] kmod[1316]: segfault at 738c08 ip 0000000000738c08 sp 00007ffdb6079c68 error 15
> > [    9.537606] tput[2716]: segfault at 0 ip           (null) sp 00007fffffffdbd0 error 14 in tput[400000+3000]
> > 					  ^^^^^^^^^^^^^^^^^
> > 
> > Looks like rIP has went off somewhere in the weeds.
> > Hmmm...
> > 
> > [    4.593374] grep[998]: segfault at 7ffc3a9f4378 ip 00007fb8409fe1df sp 00007ffc3a9f4378 error 4 in ld-2.13.so[7fb8409e8000+20000]
> > [    4.593374] grep[998]: segfault at 7ffc3a9f4378 ip 00007fb8409fe1df sp 00007ffc3a9f4378 error 4 in ld-2.13.so[7fb8409e8000+20000]
> > 
> > [    7.160423] sed[1999]: segfault at 7ffe9998f778 ip 00007f37deef0b52 sp 00007ffe9998f778 error 4 in libc-2.13.so[7f37dee18000+182000]
> > 
> > [    4.593374] grep[998]: segfault at 7ffc3a9f4378 ip 00007fb8409fe1df sp 00007ffc3a9f4378 error 4 in ld-2.13.so[7fb8409e8000+20000]
> > [    7.160423] sed[1999]: segfault at 7ffe9998f778 ip 00007f37deef0b52 sp 00007ffe9998f778 error 4 in libc-2.13.so[7f37dee18000+182000]
> > 
> > [    4.593374] grep[998]: segfault at 7ffc3a9f4378 ip 00007fb8409fe1df sp 00007ffc3a9f4378 error 4 in ld-2.13.so[7fb8409e8000+20000]
> > [    7.160423] sed[1999]: segfault at 7ffe9998f778 ip 00007f37deef0b52 sp 00007ffe9998f778 error 4 in libc-2.13.so[7f37dee18000+182000]
> > [    5.607611] sed[1350]: segfault at 7ffddd4a4bf0 ip 00007ff24a11fafc sp 00007ffddd4a4bf0 error 4 in libc-2.13.so[7ff24a050000+182000]
> 
> This does not look entirely random.
> Can you take a look what's at those locations in ld-2.13.so and libc-2.13.so?

The interesting thing is that the segfaulting address is the stack
pointer.

Let me see if I'd get the math right:

[    4.593374] grep[998]: segfault at 7ffc3a9f4378 ip 00007fb8409fe1df sp 00007ffc3a9f4378 error 4 in ld-2.13.so[7fb8409e8000+20000]

0x7fb8409fe1df - 0x7fb8409e8000 = 0x161df

   161cf:       90                      nop
   161d0:       b8 02 00 00 00          mov    $0x2,%eax
   161d5:       0f 05                   syscall
   161d7:       48 3d 01 f0 ff ff       cmp    $0xfffffffffffff001,%rax
   161dd:       73 01                   jae    161e0 <calloc+0xb60>
   161df:       c3                      retq
   161e0:       48 8d 0d 9d af 20 00    lea    0x20af9d(%rip),%rcx        # 221184 <_rtld_global+0x1144>
   161e7:       31 d2                   xor    %edx,%edx
   161e9:       48 29 c2                sub    %rax,%rdx
   161ec:       89 11                   mov    %edx,(%rcx)
   161ee:       48 83 c8 ff             or     $0xffffffffffffffff,%rax
   161f2:       eb eb                   jmp    161df <calloc+0xb5f>

Interesting, RETQ. So this pops RIP from the stack and we segfault at
the stack address. syscall 2 looks like open().

The next segfault line above is the same.




[    7.160423] sed[1999]: segfault at 7ffe9998f778 ip 00007f37deef0b52 sp 00007ffe9998f778 error 4 in libc-2.13.so[7f37dee18000+182000]

0x7f37deef0b52 - 0x7f37dee18000 = 0xd8b52

Whoops, RETQ again:

00000000000d8b40 <mmap>:
   d8b40:       49 89 ca                mov    %rcx,%r10
   d8b43:       b8 09 00 00 00          mov    $0x9,%eax
   d8b48:       0f 05                   syscall
   d8b4a:       48 3d 01 f0 ff ff       cmp    $0xfffffffffffff001,%rax
   d8b50:       73 01                   jae    d8b53 <mmap+0x13>
   d8b52:       c3                      retq
   d8b53:       48 8b 0d be c2 2a 00    mov    0x2ac2be(%rip),%rcx        # 384e18 <_IO_file_jumps+0x918>
   d8b5a:       31 d2                   xor    %edx,%edx
   d8b5c:       48 29 c2                sub    %rax,%rdx
   d8b5f:       64 89 11                mov    %edx,%fs:(%rcx)
   d8b62:       48 83 c8 ff             or     $0xffffffffffffffff,%rax
   d8b66:       eb ea                   jmp    d8b52 <mmap+0x12>

This time syscall 9, mmap.

So for some reason we manage to corrupt the stack after some syscalls...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 20769 bytes --]