On Wed, Mar 14, 2012 at 05:35:04PM -0400, Steven Schveighoffer wrote: [...] > I get that. What I was saying is, I thought even the signal handler > uses the stack (thereby it would abort if invalid). And even if it > doesn't, simply accessing the stack by loading it into a register > should be sufficient to "test" and see if the stack is valid to use > (i.e. cause another SEGV inside the signal handler forcing an abort > so we don't have an infinite loop).
That's a good idea. So the signal handler reads the top of the stack into EAX (since we're already overwriting EAX anyway), and if the stack is invalid, that will segfault and abort the program. If that doesn't abort, then assume the stack is valid and proceed with the hack to divert the return address to the throwing handler. However, this still assumes that ESP is either valid or null. If the segfault was caused by, say, an exploit attempt, then ESP may be non-null but not pointing to a valid stack either. It's conceivable that someone might try to exploit a D program by crafting a bad stack and pointing ESP at it, then triggering a segfault intentionally. (The bad stack could, for example, contain strange stack frames that causes the stack unwinder to do something unintended, like execute arbitrary code.) I don't know how to solve this, though. T -- There is no gravity. The earth sucks.