Re: [tip:x86/asm] x86/asm/entry/64: Remove unused thread_struct::usersp
From: Borislav Petkov
Date: Tue Mar 17 2015 - 03:10:13 EST
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:
config.gz
Description: application/gzip