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

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

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