All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: Jiri Slaby <jslaby@suse.cz>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	stable <stable@vger.kernel.org>,
	lwn@lwn.net, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: BUG: unable to handle kernel paging request from pty_write [was: Linux 4.4.2]
Date: Fri, 26 Feb 2016 09:52:10 -0800	[thread overview]
Message-ID: <56D090CA.7050508@hurleysoftware.com> (raw)
In-Reply-To: <56D01331.5030401@suse.cz>

On 02/26/2016 12:56 AM, Jiri Slaby wrote:
> On 02/26/2016, 01:38 AM, Linus Torvalds wrote:
>> On Thu, Feb 25, 2016 at 1:32 PM, Jiri Slaby <jslaby@suse.cz> wrote:
>>>
>>> Interestingly, RBP contains address inside try_to_wake_up --
>>> ffffffff810a535a (dunno why) which is:
>>> ffffffff810a5355:       e8 66 a0 ff ff          callq  ffffffff8109f3c0
>>> <ttwu_stat>
>>> ffffffff810a535a:       e9 9d fe ff ff          jmpq   ffffffff810a51fc
>>> <try_to_wake_up+0x3c>
>>>
>>> ttwu_stat does in the begginning:
>>> mov    $0x16e80,%r14
>>>
>>> which is what we actually still have in r14 when it crashes. The first
>>> ttwu_stat's "if" has to go through the true branch (otherwise r14 would
>>> be overwritten).
>>
>> Hmm. That does sound very much like it might be ttwu_stat() that has
>> gotten the stack frame wrong, and when finishes exits, it does
>>
>>         popq    %rbp
>>         ret
>>
>> but in fact it popped the return address, and then returned to a crazy address.
>>
>> Which sounds like a corrupted stack pointer (not a corrupted stack).

So more analysis would seem to confirm that RSP has been bumped +8
while in ttwu_stat() so when the epilog executed, register restore
was off by 1 qword. However, there's nothing in ttwu_stat() that
results in stack pointer offset by +1 qword from prolog.

Below I highlighted key instructions from try_to_wake_up() => ttwu_stat() and
what presumably was the resultant stack state at each instruction:


call try_to_wake_up   ffffffff810a5585  \
push rbp              ffff8800bb2a7c90   |
push r15              0000000000010e30   |
push r14              0000000000000005   |
push r13              ffff88017ed2a830   |- values from stack trace
push r12              ffff880234e26a08   |
push rbx              ffff88017ee19f00   |
sub  0x10, rsp        000000008146e197   /
                      ffff88023fd40000   => rip @ crash

call raw_spin_lock_irqsave
mov  rax, r13
mov  0x16e80, r15

mov  1, r12d
call ttwu_stat        ffffffff810a535a   => rbp @ crash
push rbp              ffff8800bb2a7c80   => r15 @ crash
push r15              0000000000016e80   => r14 @ crash
push r14              ffff8800bb37e180   => r13 @ crash
push r13              0000000000000046   => r12 @ crash
push r12              0000000000000001   => rbx @ crash
push rbx                    ???
sub  8, rsp                 ???


So in addition to rbp <= ret addr and r15 <= saved rbp, note also

  rbx <= saved r12 (== 1)
  r12 <= saved r13 (rflags == 00046)
  r14 <= saved r15 (== 0x16e80)

which neatly corresponds to the ttwu_stat() epilog if rsp has
been offset by +1 qword.


Regards,
Peter Hurley

  parent reply	other threads:[~2016-02-26 17:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-17 20:37 Linux 4.4.2 Greg KH
2016-02-17 20:37 ` Greg KH
2016-02-25 10:12 ` BUG: unable to handle kernel paging request from pty_write [was: Linux 4.4.2] Jiri Slaby
2016-02-25 18:40   ` Peter Hurley
2016-02-25 19:09     ` Linus Torvalds
2016-02-25 19:23       ` Steven Rostedt
2016-02-26  8:25         ` Jiri Slaby
2016-02-25 20:32       ` Peter Hurley
2016-02-25 20:51         ` Linus Torvalds
2016-02-25 21:32           ` Jiri Slaby
2016-02-25 22:33             ` Peter Hurley
2016-02-26  0:38               ` Peter Hurley
2016-02-26  8:45                 ` Jiri Slaby
2016-02-26  0:38             ` Linus Torvalds
2016-02-26  8:56               ` Jiri Slaby
2016-02-26  9:23                 ` Jiri Slaby
2016-02-26  9:50                   ` Jiri Slaby
2016-02-26 16:34                     ` Greg KH
2016-02-26 17:12                 ` Linus Torvalds
2016-02-29 15:45                   ` Paolo Bonzini
2016-02-26 17:52                 ` Peter Hurley [this message]
2016-02-25 21:43           ` Peter Hurley
2016-02-25 22:00           ` Jiri Kosina
2016-02-26  8:31             ` Jiri Slaby
2016-02-26  8:15     ` Jiri Slaby
  -- strict thread matches above, loose matches on Subject: below --
2016-02-26 18:05 Linus Torvalds
2016-02-26 18:17 ` Borislav Petkov
2016-02-26 18:18 ` Peter Hurley
2016-02-26 19:44 ` Linus Torvalds
2016-02-26 19:59   ` Robert Święcki
2016-02-29  7:39     ` Jiri Slaby
2016-02-29 12:43       ` Henrique de Moraes Holschuh

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=56D090CA.7050508@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lwn@lwn.net \
    --cc=rostedt@goodmis.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.