On Fri, 31 Aug 2007, Rusty Russell wrote: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 -
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Evgeniy Polyakov | Re: [BUG] New Kernel Bugs |
git: | |
| Gerrit Renker | [PATCH 28/37] dccp: Integration of dynamic feature activation - part 3 (client side) |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Tantilov, Emil S | WARNING: at include/net/sock.h:417 udp_lib_unhash |
