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
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 handler is running. The
12 matches
Mail list logo
