Chris Wedgwood wrote:
> By the way, the context stored on the stack is entirely a user
> space context, however it does include some information from the
> kernel that may be useful to user space, such as a page fault
> address.
>
> I actually (ab)used this for userspace paging wi
Kurt Roeckx wrote:
> You should never "return" from userspace to kernelspace. The
> only way to go from user space to kernel space should be by using
> a system call.
That does actually happen on x86. The kernel puts a small code fragment
called the "trampoline" on the user mode stack, which is
On Tue, May 29, 2001 at 01:30:30AM +0200, Kurt Roeckx wrote:
> You should never "return" from userspace to kernelspace. The
> only way to go from user space to kernel space should be by using
> a system call.
If you were able to return to kernel space, it already means
you're running as kernel i
On Tue, May 29, 2001 at 12:12:56AM +0100, Russell King wrote:
> On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote:
> > Please correct me if i'm wrong but it seems to me that i've stumbled on
> > really BIG security hole in the signal handling code.
>
> I don't think there's problem, u
On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote:
> Please correct me if i'm wrong but it seems to me that i've stumbled on
> really BIG security hole in the signal handling code.
I don't think there's problem, unless I'm missing something.
> The problem IMO is that the signal handl
On Tue, May 29, 2001 at 12:30:03AM +0200, Vadim Lebedev wrote:
> Kurt,
>
> Maybe i'm missing something but it seems that during execution of the signal
> handler, user mode stack contains kernel mode context...
> Hence the security hole
It's rather complicated how things work.
Both the user and
>
> Hi folks,
>
> Please correct me if i'm wrong but it seems to me that i've stumbled on
> really BIG security hole in the signal handling code.
> The problem IMO is that the signal handling code stores a processor context
> on the user-mode stack frame which is active while
> the signal handle
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, May 29, 2001 12:29 AM
Subject: Re: Potenitial security hole in the kernel
> On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote:
> > Hi folks,
> >
> > Please correct me if i'm wrong but it
ev" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, May 29, 2001 12:21 AM
Subject: Re: Potenitial security hole in the kernel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote:
> Hi folks,
>
> Please correct me if i'm wrong but it seems to me that i've stumbled on
> really BIG security hole in the signal handling code.
> The problem IMO is that the signal handling code stores a processor context
> on the use
>Suppose the signal handler modifies this context frame for example by
>storing into the PC slot address of the panic routine
>then when handler will exit panic will be called with obvious results.
You can't execute panic() - or any other kernel function - in user mode.
The application can write
11 matches
Mail list logo
