linux-kernel - Re: BUG: unable to handle kernel paging request from pty

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LRH.2.00.1602252257480.27246@gjva.wvxbf.pm>
Date:	Thu, 25 Feb 2016 23:00:19 +0100 (CET)
From:	Jiri Kosina <jikos@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Peter Hurley <peter@...leysoftware.com>,
	Jiri Slaby <jslaby@...e.cz>,
	Greg KH <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	stable <stable@...r.kernel.org>, lwn@....net,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: BUG: unable to handle kernel paging request from pty_write [was:
 Linux 4.4.2]

On Thu, 25 Feb 2016, Linus Torvalds wrote:

> >>   tty_flip_buffer_push ->
> >>     (queue_work is inline) ->
> >>     queue_work_on ->
> >>       __queue_work ->
> >>         insert_work ->
> >>           (wake_up_worker is inlined)
> >>           wake_up_process ->
> >
> >               try_to_wake_up ->
> >
> >>             *insane non-code address*
> 
> The thing is, we don't actually have that try_to_wake_up() on the
> stack in the oops report. There are other thigns on the stack, but the
> first stack entry that is dumped that is a text address is that
> "ffffffff810a5585" which is wake_up_process.
> 
> That's why I said it might be stack corruption: we might be returning
> from try_to_wake_up(), but with a corrupt stack entry, and returning
> to garbage.
>
> If it was one of the calls _in_ try_to_wake_up() that called to insane 
> code, I would have expected to see try_to_wake_up on the stack.

try_to_wake_up() is very likely to be inlined into wake_up_process(), and 
therefore in such cases will never be on the stack as a return address; 
it'll always be wake_up_process().

-- 
Jiri Kosina
SUSE Labs