Patch for arch/um/kernel/trap_kern.c to fix bad panic

uml-devel azu 3 participants 11 messages Jun 28, 2004 – Sep 5, 2004 User-mode Linux (UML)

lore

Share & tools

lore

azu

author

2004-06-28 11:34 UTC #0 lore raw

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

arch/um/kernel/trap_kern.c 2004-06-28 13:08:52.000000000 +0200 renamed from arch/um/kernel/trap_kern.c 2004-06-28 13:08:41.000000000 +0200 +2 -0

@@ -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
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

BlaisorBlade

2004-06-29 18:22 UTC #1 lore raw

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

Quoted 8 lines

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 {

Signature · 14 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

azu

author

2004-06-30 09:59 UTC #2 lore raw

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

Quoted 14 lines · BlaisorBlade

Alle 13:39, lunedì 28 giugno 2004, azu ha scritto:
Quoted 10 lines
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.

Quoted 5 lines

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

/*
* trigger.c - triggers panic("Kernel stack overflow") in UML *
* 20040630, [email protected]
*/

#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");
}

BlaisorBlade

2004-07-01 16:49 UTC #3 lore raw

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

Alle 12:04, mercoledì 30 giugno 2004, azu ha scritto:

Quoted 2 lines

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.

Quoted 11 lines

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)

Quoted 2 lines

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 <[email protected]>

---

 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);

Signature · 15 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Alex Züpke

author

2004-07-01 17:52 UTC #4 lore raw

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

Quoted 12 lines

 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

arch/um/kernel/trap_kern.c 2004-06-28 13:08:52.000000000 +0200 int handle_page_fault(unsigned long addr · line 60

Quoted 8 lines

arch/um/kernel/trap_kern.c 2004-06-28 13:08:52.000000000 +0200 renamed from arch/um/kernel/trap_kern.c 2004-06-28 13:08:41.000000000 +0200 +1 -1

@@ -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

BlaisorBlade

2004-07-01 19:19 UTC #5 lore raw

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

Alle 19:57, giovedì 1 luglio 2004, Alex Züpke ha scritto:

Quoted 21 lines

Quoted 10 lines
 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
arch/um/kernel/trap_kern.c 2004-06-28 13:08:52.000000000 +0200 int handle_page_fault(unsigned long addr · line 60
Quoted 8 lines
arch/um/kernel/trap_kern.c 2004-06-28 13:08:52.000000000 +0200 renamed from arch/um/kernel/trap_kern.c 2004-06-28 13:08:41.000000000 +0200 +1 -1
@@ -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,

Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 2 lines

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:

Quoted 1 line

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.

Signature · 14 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

BlaisorBlade

2004-07-03 18:11 UTC #6 lore raw

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

Alle 21:33, giovedì 1 luglio 2004, BlaisorBlade ha scritto:

Quoted 16 lines

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.
Quoted 6 lines
Maybe Jeff remembers the intention of this panic,
because the whole
	if(page == (unsigned long) current + PAGE_SIZE)
		panic("Kernel stack overflow");

Quoted 9 lines

Quoted 1 line
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.
Quoted 2 lines
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).

Signature · 2 lines

Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

From: Alex Züpke <[email protected]>, 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 <[email protected]> for first seeing this bug, and providing a test program:

/*
* trigger.c - triggers panic("Kernel stack overflow") in UML *
* 20040630, [email protected]
*/

#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 <[email protected]>

---

 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(-)

arch/um/kernel/trap_kern.c renamed from arch/um/kernel/trap_kern.c~check_is_user_before_panic +1 -1

diff -puN arch/um/kernel/trap_kern.c~check_is_user_before_panic arch/um/kernel/trap_kern.c
@@ -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);

arch/um/kernel/skas/uaccess.c renamed from arch/um/kernel/skas/uaccess.c~check_is_user_before_panic +1 -1

diff -puN arch/um/kernel/skas/uaccess.c~check_is_user_before_panic arch/um/kernel/skas/uaccess.c
@@ -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);

arch/um/kernel/process_kern.c renamed from arch/um/kernel/process_kern.c~check_is_user_before_panic +1 -1

diff -puN arch/um/kernel/process_kern.c~check_is_user_before_panic arch/um/kernel/process_kern.c
@@ -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));
 }

BlaisorBlade

2004-08-20 10:10 UTC #7 lore raw

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

Alle 20:25, sabato 3 luglio 2004, BlaisorBlade ha scritto:

Quoted 1 line

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.

Quoted 1 line

uml-linux-2.6.7/arch/um/kernel/process_kern.c~check_is_user_before_panic

2004-07-03 16:41:39.473637592 +0200

Quoted 1 line

+++ uml-linux-2.6.7-paolo/arch/um/kernel/process_kern.c 2004-07-03

17:53:21.867574296 +0200

Quoted 10 lines

arch/um/kernel/process_kern.c renamed from arch/um/kernel/process_kern.c~check_is_user_before_panic +1 -1

@@ -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));
 }

Signature · 14 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Jeff Dike

2004-08-20 14:07 UTC #8 lore raw

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

Quoted 5 lines · [email protected] 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 [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

BlaisorBlade

2004-09-05 19:42 UTC #9 lore raw

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

Quoted 9 lines · Jeff Dike

Quoted 5 lines · [email protected] 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

Signature · 14 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

BlaisorBlade

2004-07-01 16:49 UTC #10 lore raw

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

In reply to azu

Alle 12:04, mercoledì 30 giugno 2004, azu ha scritto:

Quoted 2 lines

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.

Signature · 15 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel