[14749] in bugtraq
Re: Solaris 7 x86 lpset exploit.
daemon@ATHENA.MIT.EDU (Peter da Silva)
Tue May 2 18:32:17 2000
Message-Id: <200005011559.KAA0000005929@grendel.eng.baileynm.com>
Date: Mon, 1 May 2000 10:59:00 -0500
Reply-To: Peter da Silva <peter@GRENDEL.ENG.BAILEYNM.COM>
From: Peter da Silva <peter@GRENDEL.ENG.BAILEYNM.COM>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200004291624.MAA19828@twig.rodents.montreal.qc.ca>
In article <200004291624.MAA19828@twig.rodents.montreal.qc.ca>,
der Mouse <mouse@RODENTS.MONTREAL.QC.CA> wrote:
> data around. Another possible way around it would be to cause gcc to
> keep part of the stack in the data segment, out of what the kernel
> thinks of as the stack, and have it do its trampolines there. This
> runs into big problems with setjmp and other nonlocal exits, and
> possibly with signal handlers as well.)
You could handle that by having a frame pointer on the processor stack
point into the function's executable stack frame (if it has one) on the
trampoline stack, rather than having a permanent stack pointer into this
space. I don't think there would be any issues with this, unless you're
trying to use setjmp/longjmp for coroutines or something perverse like
that.
