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.LFD.0.999.0708302140480.25853@woody.linux-foundation.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ