linux-kernel - Re: [PATCH] Fix out-by-one error in traps.c

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]

Date:	Thu, 30 Aug 2007 21:44:49 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, lguest <lguest@...abs.org>,
	Frederik Deweerdt <deweerdt@...e.fr>, Andi Kleen <ak@....de>
Subject: Re: [PATCH] Fix out-by-one error in traps.c

On Fri, 31 Aug 2007, Rusty Russell wrote:
>
> We don't care if ebp is on the stack, we care about ebp + 4.  Without
> this, lguest (with CONFIG_DEBUG_LOCKDEP) can touch a page unmapped by
> CONFIG_DEBUG_PAGEALLOC.

Hmm.. This *really* cannot happen with a normal kernel - it implies that 
the stack has crossed into an invalid page. 

Why is that allowed with lguest? What kind of code could validly *ever* 
come in here and cause problems?

I'm getting the nervous feeling that lguest is really doing things that 
shouldn't be done, or is using normal kernel functions in ways that they 
should not be used. 

In other words, yes, we load off "ebp+4", but I really don't see it being 
a valid situation wher ebp itself isn't also a valid stack frame. The 
stack is not sized for "off-by-one" errors - we're supposed to always have 
plenty of stack space free, and if you care about "off-by-one", you're not 
just living on the edge, you're way beyond it!

IOW, please explain why/how lguest ever triggers a case where this would 
possibly matter!

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/