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
![]() |