LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: linux-tip-commits@vger.kernel.org, linux-kernel@vger.kernel.org,
keescook@chromium.org, ast@plumgrid.com, fweisbec@gmail.com,
oleg@redhat.com, tglx@linutronix.de,
torvalds@linux-foundation.org, hpa@zytor.com, mingo@kernel.org,
wad@chromium.org, rostedt@goodmis.org
Subject: Re: [tip:x86/asm] x86/asm/entry/64: Remove unused thread_struct::usersp
Date: Tue, 17 Mar 2015 08:08:30 +0100 [thread overview]
Message-ID: <20150317070830.GA19645@pd.tnic> (raw)
In-Reply-To: <55075736.7030003@redhat.com>
[-- 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 --]
next prev parent reply other threads:[~2015-03-17 7:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-10 10:45 [PATCH 2/4] x86: entry_64.S: remove stub_iopl Denys Vlasenko
2015-03-10 10:45 ` [PATCH 4/4] x86: entry_64.S: remove unused thread_struct::usersp Denys Vlasenko
2015-03-11 12:55 ` Borislav Petkov
2015-03-11 15:19 ` Denys Vlasenko
2015-03-16 12:05 ` [tip:x86/asm] x86/asm/entry/64: Remove unused thread_struct:: usersp tip-bot for Denys Vlasenko
2015-03-16 16:47 ` Borislav Petkov
2015-03-16 22:20 ` [tip:x86/asm] x86/asm/entry/64: Remove unused thread_struct::usersp Denys Vlasenko
2015-03-17 7:08 ` Borislav Petkov [this message]
2015-03-17 7:13 ` Ingo Molnar
2015-03-17 7:21 ` Ingo Molnar
2015-03-17 7:39 ` Borislav Petkov
2015-03-17 12:22 ` Denys Vlasenko
2015-03-17 12:51 ` Denys Vlasenko
2015-03-17 7:51 ` Ingo Molnar
2015-03-17 8:06 ` Borislav Petkov
2015-03-17 8:27 ` Ingo Molnar
2015-03-17 9:01 ` Borislav Petkov
2015-03-11 12:08 ` [PATCH 2/4] x86: entry_64.S: remove stub_iopl Borislav Petkov
2015-03-16 12:05 ` [tip:x86/asm] x86/asm/entry/64: Remove stub_iopl tip-bot for Denys Vlasenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150317070830.GA19645@pd.tnic \
--to=bp@alien8.de \
--cc=ast@plumgrid.com \
--cc=dvlasenk@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=wad@chromium.org \
--subject='Re: [tip:x86/asm] x86/asm/entry/64: Remove unused thread_struct::usersp' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).