[uml-devel] Patch for arch/um/kernel/trap_kern.c to fix bad panic

[uml-devel] Patch for arch/um/kernel/trap_kern.c to fix bad panic

[azu]

Hi,

I triggered the following panic from userspace in skas mode
by mapping pages above 0xa0000000 ...

The check is useless in skas-mode (kernel faults get filtered
in segv() before handle_page_fault() is called),
so I added an ifdef for tt mode.


-Alex


--- orig/arch/um/kernel/trap_kern.c     2004-06-28 13:08:41.000000000 +0200
+++ u4/arch/um/kernel/trap_kern.c       2004-06-28 13:08:52.000000000 +0200
@@ -52,8 +52,10 @@
         if(is_write && !(vma->vm_flags & VM_WRITE))
                 goto out;
         page = address & PAGE_MASK;
+#ifdef CONFIG_MODE_TT
         if(page == (unsigned long) current + PAGE_SIZE)
                 panic("Kernel stack overflow");
+#endif
         pgd = pgd_offset(mm, page);
         pmd = pmd_offset(pgd, page);
         do {




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Patch for arch/um/kernel/trap_kern.c to fix bad panic

[BlaisorBlade]

Alle 13:39, lunedì 28 giugno 2004, azu ha scritto:
> Hi,

> I triggered the following panic from userspace in skas mode
> by mapping pages above 0xa0000000 ...

> The check is useless in skas-mode (kernel faults get filtered
> in segv() before handle_page_fault() is called),
> so I added an ifdef for tt mode.

This is a more sensible version of the patch (with runtime checking instead 
that compile time), if I did not overlook anything: it must be an if(mode_tt). 
I always compile in TT mode and normally don't use it (and sometimes UML does 
not compile otherwise), and the patch must still work.


However, I don't think this is the proper fix: please elaborate a bit more. 
Segv() works the same way under TT and SKAS, and I think that more likely 
there were an actual stack overflow (try to increase 
CONFIG_KERNEL_STACK_ORDER and try to re-get the panic).

diff -puN arch/um/kernel/trap_kern.c~silly_panic arch/um/kernel/trap_kern.c
--- uml-linux-2.6.7/arch/um/kernel/trap_kern.c~silly_panic	2004-06-28 
21:42:06.025387464 +0200
+++ uml-linux-2.6.7-paolo/arch/um/kernel/trap_kern.c	2004-06-28 
21:43:47.676934080 +0200
@@ -54,8 +54,10 @@ int handle_page_fault(unsigned long addr
 	if(is_write && !(vma->vm_flags & VM_WRITE)) 
 		goto out;
 	page = address & PAGE_MASK;
-	if(page == (unsigned long) current_thread + PAGE_SIZE)
-		panic("Kernel stack overflow");
+	if (mode_tt) {
+		if(page == (unsigned long) current_thread + PAGE_SIZE)
+			panic("Kernel stack overflow");
+	}
 	pgd = pgd_offset(mm, page);
 	pmd = pmd_offset(pgd, page);
 	do {

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] bad panic "Kernel stack overflow" - demo exploit

[azu]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

BlaisorBlade wrote:
> Alle 13:39, lunedì 28 giugno 2004, azu ha scritto:
> 
>>Hi,
> 
> 
>>I triggered the following panic from userspace in skas mode
>>by mapping pages above 0xa0000000 ...
> 
> 
>>The check is useless in skas-mode (kernel faults get filtered
>>in segv() before handle_page_fault() is called),
>>so I added an ifdef for tt mode.
> 
> 
> This is a more sensible version of the patch (with runtime checking instead 
> that compile time), if I did not overlook anything: it must be an if(mode_tt). 
> I always compile in TT mode and normally don't use it (and sometimes UML does 
> not compile otherwise), and the patch must still work.
> 
> 
> However, I don't think this is the proper fix: please elaborate a bit more. 
> Segv() works the same way under TT and SKAS, and I think that more likely 
> there were an actual stack overflow (try to increase 
> CONFIG_KERNEL_STACK_ORDER and try to re-get the panic).
>

Paolo, your patch is the better one :-)

But it wasn't a stack overflow ...

Due to "overlapping" address spaces in skas mode,
it is possible to trigger the panic:
A userpage with the same address as current + 4096
must be valid in the vma, but not (yet) mapped to
the user:
0) addr = 0xa0000000
1) mmap a zero page to addr (valid vma) readwrite
2) fork -> mapping is now readonly
3) child writes to page
4) IF addr == current + 4096 THEN panic
5) addr += 4096
6) goto 1)

I wrote a small demo app to trigger the problem.
Limit your UML memory to 16MB or so to trigger the panic faster.



-Alex




[-- Attachment #2: trigger.c --]
[-- Type: text/x-csrc, Size: 961 bytes --]

/*
 * trigger.c - triggers panic("Kernel stack overflow") in UML
 *
 * 20040630, azu@sysgo.de
 */

#include <stdio.h>
#include <setjmp.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>

#define LOW  0xa0000000
#define HIGH 0xb0000000

int main(int argc, char **argv)
{
	unsigned long addr;
	int fd;

	fd = open("/dev/zero", O_RDWR);

	printf("This may take some time ... one more cup of coffee ...\n");

	for(addr = LOW; addr < HIGH; addr += 0x1000)
	{
		pid_t p;
		if(mmap((void*)addr, 0x1000, PROT_READ, MAP_SHARED | MAP_FIXED, fd, 0) == MAP_FAILED)
			printf("mmap failed\n");

		p = fork();
		if(p == -1)
			printf("fork failed\n");

		if(p == 0)
		{
			/* child context */
			int *p = (int *)addr;
			volatile int x;

			x = *p;
			return 0;
		}
		/* father context */
		waitpid(p, 0, 0);

		if(munmap((void*)addr, 0x1000) == -1)
			printf("munmap failed\n");
	}

	close(fd);
	printf("done\n");
}

Re: [uml-devel] bad panic "Kernel stack overflow" - demo exploit

[BlaisorBlade]

Alle 12:04, mercoledì 30 giugno 2004, azu ha scritto:
> I wrote a small demo app to trigger the problem.
> Limit your UML memory to 16MB or so to trigger the panic faster.
With the last fix I posted (the !is_user check) it does not panic. But I had 
statically linked it since I've no gcc inside UML, so I'll have to retest it.

Thanks for the analisys and the test-script.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] bad panic "Kernel stack overflow" - demo exploit

[BlaisorBlade]

Alle 12:04, mercoledì 30 giugno 2004, azu ha scritto:
> Due to "overlapping" address spaces in skas mode,
> it is possible to trigger the panic:

Yes, there are distinct address spaces; I was first confused by 
"overlapping", but now I understand.

> A userpage with the same address as current + 4096
> must be valid in the vma, but not (yet) mapped to
> the user:
> 0) addr = 0xa0000000
> 1) mmap a zero page to addr (valid vma) readwrite
> 2) fork -> mapping is now readonly
> 3) child writes to page
> 4) IF addr == current + 4096 THEN panic
> 5) addr += 4096
> 6) goto 1)
>
> I wrote a small demo app to trigger the problem.
> Limit your UML memory to 16MB or so to trigger the panic faster.

Ok... now I understand. The panic must be left there, but only if the address 
was accessed by kernel-space. Thanks for the analisys and the test-case.

Please try the attached fix; I run your trigger.c (statically linked on the 
host) and it panicked without this patch and ran fine with it applied.

Test this patch, please:

SKAS mode is like 4G/4G (here we have actually 3G/3G) for guest processes,
so when checking for kernel stack overflow, we must first make sure
we are checking a kernel-space address.

Signed-off-by: <blaisorblade_spam@yahoo.it>
---

 uml-linux-2.6.7-paolo/arch/um/kernel/trap_kern.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN arch/um/kernel/trap_kern.c~check_is_user_before_panic 
arch/um/kernel/trap_kern.c
--- uml-linux-2.6.7/arch/um/kernel/trap_kern.c~check_is_user_before_panic	
2004-06-30 21:27:59.640300880 +0200
+++ uml-linux-2.6.7-paolo/arch/um/kernel/trap_kern.c	2004-06-30 
21:28:04.043631472 +0200
@@ -54,7 +54,7 @@ int handle_page_fault(unsigned long addr
 	if(is_write && !(vma->vm_flags & VM_WRITE)) 
 		goto out;
 	page = address & PAGE_MASK;
-	if(page == (unsigned long) current_thread + PAGE_SIZE)
+	if(page == (unsigned long) current_thread + PAGE_SIZE && !is_user)
 		panic("Kernel stack overflow");
 	pgd = pgd_offset(mm, page);
 	pmd = pmd_offset(pgd, page);


-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] bad panic "Kernel stack overflow" - demo exploit

[Alex Züpke]

>  uml-linux-2.6.7-paolo/arch/um/kernel/trap_kern.c |    2 +-
>  1 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff -puN arch/um/kernel/trap_kern.c~check_is_user_before_panic 
> arch/um/kernel/trap_kern.c
> --- uml-linux-2.6.7/arch/um/kernel/trap_kern.c~check_is_user_before_panic	
> 2004-06-30 21:27:59.640300880 +0200
> +++ uml-linux-2.6.7-paolo/arch/um/kernel/trap_kern.c	2004-06-30 
> 21:28:04.043631472 +0200
> @@ -54,7 +54,7 @@ int handle_page_fault(unsigned long addr
>  	if(is_write && !(vma->vm_flags & VM_WRITE)) 
>  		goto out;
>  	page = address & PAGE_MASK;
> -	if(page == (unsigned long) current_thread + PAGE_SIZE)
> +	if(page == (unsigned long) current_thread + PAGE_SIZE && !is_user)
>  		panic("Kernel stack overflow");
>  	pgd = pgd_offset(mm, page);
>  	pmd = pmd_offset(pgd, page);
> 
> 

Hi Paolo,

checking !is_user might not help, because
skas/uaccess.c::maybe_map() calls handle_page_fault with is_user = 0
when doing copy_from/to_user stuff ...

Maybe Jeff remembers the intention of this panic,
because the whole

	if(page == (unsigned long) current + PAGE_SIZE)
		panic("Kernel stack overflow");

does not make any sense for me when checking user VMAs

On Linux 2.4.xx with 8k stacks, current+PAGE_SIZE is the upper
page of the kernel stack and always valid in kernel address space
and has nothing to do with the userspace VMAs.



-Alex




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] bad panic "Kernel stack overflow" - demo exploit

[BlaisorBlade]

Alle 19:57, giovedì 1 luglio 2004, Alex Züpke ha scritto:
> >  uml-linux-2.6.7-paolo/arch/um/kernel/trap_kern.c |    2 +-
> >  1 files changed, 1 insertion(+), 1 deletion(-)
> >
> > diff -puN arch/um/kernel/trap_kern.c~check_is_user_before_panic
> > arch/um/kernel/trap_kern.c
> > --- uml-linux-2.6.7/arch/um/kernel/trap_kern.c~check_is_user_before_panic
> > 2004-06-30 21:27:59.640300880 +0200
> > +++ uml-linux-2.6.7-paolo/arch/um/kernel/trap_kern.c	2004-06-30
> > 21:28:04.043631472 +0200
> > @@ -54,7 +54,7 @@ int handle_page_fault(unsigned long addr
> >  	if(is_write && !(vma->vm_flags & VM_WRITE))
> >  		goto out;
> >  	page = address & PAGE_MASK;
> > -	if(page == (unsigned long) current_thread + PAGE_SIZE)
> > +	if(page == (unsigned long) current_thread + PAGE_SIZE && !is_user)
> >  		panic("Kernel stack overflow");
> >  	pgd = pgd_offset(mm, page);
> >  	pmd = pmd_offset(pgd, page);
>
> Hi Paolo,
>
> checking !is_user might not help, because
> skas/uaccess.c::maybe_map() calls handle_page_fault with is_user = 0
> when doing copy_from/to_user stuff ...

Maybe you are right, and there should be some more fixes. But could you 
explain me if there is any valid reason for maybe_map to behave that way? It 
seems wrong to me, but I would wonder from it not causing bugs. But in fact 
is_user was not used by handle_page_fault, so we could just correct 
maybe_map(). Do you agree?

However if you can build a test program, that could be useful (one which 
requires UML to dereference a pointer, so calling copy_*_user.) Maybe I'll 
write one myself.

> Maybe Jeff remembers the intention of this panic,
> because the whole
>
> 	if(page == (unsigned long) current + PAGE_SIZE)
> 		panic("Kernel stack overflow");
>
> does not make any sense for me when checking user VMAs
It's obvious that it does not make sense for user faults. In fact, that code 
is called both for user and for kernel faults; and the !is_user checks 
expresses exactly your sentence. If you mean that the check for a kernel 
stack overflow is wrong, you may be right.


> On Linux 2.4.xx with 8k stacks, current+PAGE_SIZE is the upper
> page of the kernel stack and always valid in kernel address space
Yes, maybe PAGE_SIZE is wrong (I say maybe until I double and triple check 
everything); About the stack size, that depends on CONFIG_STACK_ORDER on UML:

> and has nothing to do with the userspace VMAs.

About under UML in SKAS mode, like under the 4G/4G kernel patch from Ingo 
Molnar, both the kernel and the userspace programs have 3G of virtual memory 
starting at 0. 

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] bad panic "Kernel stack overflow" - demo exploit

[BlaisorBlade]

[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]

Alle 21:33, giovedì 1 luglio 2004, BlaisorBlade ha scritto:
> Maybe you are right, and there should be some more fixes. But could you
> explain me if there is any valid reason for maybe_map to behave that way?
> It seems wrong to me, but I would wonder from it not causing bugs. But in
> fact is_user was not used by handle_page_fault, so we could just correct
> maybe_map(). Do you agree?
>
> However if you can build a test program, that could be useful (one which
> requires UML to dereference a pointer, so calling copy_*_user.) Maybe I'll
> write one myself.
>
> > Maybe Jeff remembers the intention of this panic,
> > because the whole
> >
> > 	if(page == (unsigned long) current + PAGE_SIZE)
> > 		panic("Kernel stack overflow");
> >
> > does not make any sense for me when checking user VMAs
>
> It's obvious that it does not make sense for user faults. In fact, that
> code is called both for user and for kernel faults; and the !is_user checks
> expresses exactly your sentence. If you mean that the check for a kernel
> stack overflow is wrong, you may be right.

> > On Linux 2.4.xx with 8k stacks, current+PAGE_SIZE is the upper
> > page of the kernel stack and always valid in kernel address space

Well, after replacing PAGE_SIZE with THREAD_SIZE, I remembered that the stack 
grows downward. I checked inside the fork() code (at copy_thread) that 
current (or current_thread in 2.6) is at the bottom of the stack, which goes 
down from (long) current + 2 * PAGE_SIZE to (long) current. So the overflow 
happens when address < current_thread (or address < current).

So, this is the attached patch I propose (the test program is included because 
I will not rebuild it afterwards, to send it to Jeff; I have tons of 
patches).
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

[-- Attachment #2: check_is_user_before_panic.patch --]
[-- Type: text/x-diff, Size: 3937 bytes --]


From: Alex Züpke <azu@sysgo.de>, and me
SKAS mode is like 4G/4G (here we have actually 3G/3G) for guest processes,
so when checking for kernel stack overflow, we must first make sure
we are checking a kernel-space address.
Also, correctly test for stack overflows (i.e. check if there is less
than 1k of stack left; see arch/i386/kernel/irq.c:do_IRQ()).
And also, THREAD_SIZE != PAGE_SIZE * 2, in general (though
this setting is almost never changed, so we didn't notice this1).
Thanks to the good eye of Alex Züpke <azu@sysgo.de> for first seeing this bug,
and providing a test program:


/*
 * trigger.c - triggers panic("Kernel stack overflow") in UML
 *
 * 20040630, azu@sysgo.de
 */

#include <stdio.h>
#include <setjmp.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>

#define LOW  0xa0000000
#define HIGH 0xb0000000

int main(int argc, char **argv)
{
	unsigned long addr;
	int fd;

	fd = open("/dev/zero", O_RDWR);

	printf("This may take some time ... one more cup of coffee ...\n");

	for(addr = LOW; addr < HIGH; addr += 0x1000)
	{
		pid_t p;
		if(mmap((void*)addr, 0x1000, PROT_READ, MAP_SHARED | MAP_FIXED, fd, 0) == MAP_FAILED)
			printf("mmap failed\n");

		p = fork();
		if(p == -1)
			printf("fork failed\n");

		if(p == 0)
		{
			/* child context */
			int *p = (int *)addr;
			volatile int x;

			x = *p;
			return 0;
		}
		/* father context */
		waitpid(p, 0, 0);

		if(munmap((void*)addr, 0x1000) == -1)
			printf("munmap failed\n");
	}

	close(fd);
	printf("done\n");
}

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it>
---

 uml-linux-2.6.7-paolo/arch/um/kernel/process_kern.c |    2 +-
 uml-linux-2.6.7-paolo/arch/um/kernel/skas/uaccess.c |    2 +-
 uml-linux-2.6.7-paolo/arch/um/kernel/trap_kern.c    |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff -puN arch/um/kernel/trap_kern.c~check_is_user_before_panic arch/um/kernel/trap_kern.c
--- uml-linux-2.6.7/arch/um/kernel/trap_kern.c~check_is_user_before_panic	2004-06-30 21:34:05.000000000 +0200
+++ uml-linux-2.6.7-paolo/arch/um/kernel/trap_kern.c	2004-07-03 17:53:23.637305256 +0200
@@ -54,7 +54,7 @@ int handle_page_fault(unsigned long addr
 	if(is_write && !(vma->vm_flags & VM_WRITE)) 
 		goto out;
 	page = address & PAGE_MASK;
-	if(page == (unsigned long) current_thread + PAGE_SIZE)
+	if(address < (unsigned long) current_thread + 1024 && !is_user)
 		panic("Kernel stack overflow");
 	pgd = pgd_offset(mm, page);
 	pmd = pmd_offset(pgd, page);
diff -puN arch/um/kernel/skas/uaccess.c~check_is_user_before_panic arch/um/kernel/skas/uaccess.c
--- uml-linux-2.6.7/arch/um/kernel/skas/uaccess.c~check_is_user_before_panic	2004-07-02 12:55:21.000000000 +0200
+++ uml-linux-2.6.7-paolo/arch/um/kernel/skas/uaccess.c	2004-07-02 13:01:11.000000000 +0200
@@ -25,7 +25,7 @@ static unsigned long maybe_map(unsigned 
 	int dummy_code;
 
 	if(IS_ERR(phys) || (is_write && !pte_write(pte))){
-		err = handle_page_fault(virt, 0, is_write, 0, &dummy_code);
+		err = handle_page_fault(virt, 0, is_write, 1, &dummy_code);
 		if(err)
 			return(0);
 		phys = um_virt_to_phys(current, virt, NULL);
diff -puN arch/um/kernel/process_kern.c~check_is_user_before_panic arch/um/kernel/process_kern.c
--- uml-linux-2.6.7/arch/um/kernel/process_kern.c~check_is_user_before_panic	2004-07-03 16:41:39.473637592 +0200
+++ uml-linux-2.6.7-paolo/arch/um/kernel/process_kern.c	2004-07-03 17:53:21.867574296 +0200
@@ -165,7 +165,7 @@ int copy_thread(int nr, unsigned long cl
 {
 	p->thread = (struct thread_struct) INIT_THREAD;
 	p->thread.kernel_stack = 
-		(unsigned long) p->thread_info + 2 * PAGE_SIZE;
+		(unsigned long) p->thread_info + THREAD_SIZE;
 	return(CHOOSE_MODE_PROC(copy_thread_tt, copy_thread_skas, nr, 
 				clone_flags, sp, stack_top, p, regs));
 }
_

Re: [uml-devel] bad panic "Kernel stack overflow" - demo exploit

[BlaisorBlade]

Alle 20:25, sabato 3 luglio 2004, BlaisorBlade ha scritto:
> Alle 21:33, giovedì 1 luglio 2004, BlaisorBlade ha scritto:

About this hunk of the patch, sorry. I tested the patch well, then I added 
this part without testing, and understood this a lot of time after. Sorry. 
Since CONFIG_KERNEL_STACK_ORDER is usually 2, THREAD_SIZE becomes 16k (I've 
just realized this). So this hunk is wrong. The rest works very happily.
> uml-linux-2.6.7/arch/um/kernel/process_kern.c~check_is_user_before_panic    
2004-07-03 16:41:39.473637592 +0200
> +++ uml-linux-2.6.7-paolo/arch/um/kernel/process_kern.c 2004-07-03 
17:53:21.867574296 +0200
> @@ -165,7 +165,7 @@ int copy_thread(int nr, unsigned long cl
>  {
>         p->thread = (struct thread_struct) INIT_THREAD;
>         p->thread.kernel_stack = 
> -               (unsigned long) p->thread_info + 2 * PAGE_SIZE;
> +               (unsigned long) p->thread_info + THREAD_SIZE;
>         return(CHOOSE_MODE_PROC(copy_thread_tt, copy_thread_skas, nr, 
>                                 clone_flags, sp, stack_top, p, regs));
>  }
> _

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] bad panic "Kernel stack overflow" - demo exploit

[Jeff Dike]

blaisorblade_spam@yahoo.it said:
> About this hunk of the patch, sorry. I tested the patch well, then I
> added  this part without testing, and understood this a lot of time
> after. Sorry.  Since CONFIG_KERNEL_STACK_ORDER is usually 2,
> THREAD_SIZE becomes 16k (I've  just realized this). So this hunk is
> wrong. The rest works very happily. 

BTW, I just got rid of thread.kernel_stack since it wasn't really needed
for anything.  So that code is gone, plus some more in other places.

				Jeff



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] bad panic "Kernel stack overflow" - demo exploit

[BlaisorBlade]

On Friday 20 August 2004 17:09, Jeff Dike wrote:
> blaisorblade_spam@yahoo.it said:
> > About this hunk of the patch, sorry. I tested the patch well, then I
> > added  this part without testing, and understood this a lot of time
> > after. Sorry.  Since CONFIG_KERNEL_STACK_ORDER is usually 2,
> > THREAD_SIZE becomes 16k (I've  just realized this). So this hunk is
> > wrong. The rest works very happily.
>
> BTW, I just got rid of thread.kernel_stack since it wasn't really needed
> for anything.  So that code is gone, plus some more in other places.
Yes, and I've seen you saying that the "kernel stack overflow" message is 
useless because it will never run, since the stack overflowed and then 
removing it altogether. Well, would you give a look at the various "kernel 
stack overflow" messages appearing from various users? Simply search on the 
ML archives (especially uml-user) to find them.

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel