[grsec] followup about expand_stack

Brad Spengler spender at grsecurity.net
Sat Jan 20 15:07:03 EST 2007


On Sat, Jan 20, 2007 at 04:41:38PM -0200, Carlos Carvalho wrote:
> What I should have added in the previous msg. is that I don't know if
> the segfault is due to a failure in the kernel or in the poc code. I
> don't know how to decipher the addresses... They show a kdb stack
> trace that seems to point to the kernel. It must be checked if it's
> true.

The POC should have a signal handler in it for SIGSEGV.  Once this is 
added, it'll execute fully.  I've did some initial analysis of it: it 
seems to work on both 2.4 and 2.6, in both cases causing a BUG() in the 
kernel.  I have a preliminary workaround/fix, but haven't been able to 
reach the PaX team yet to determine if there are deeper-seated issues 
that this is just a single manifestation of.  I'm not convinced yet 
though that this is anything more than a DoS (especially with 
uderef/kernexec) since the mappings that seem to be overlapping are a 
normal userland mapping and a mirrored mapping, but again this is 
something I'll have to confirm with the PaX team.  Since this is a vma 
mirroring bug, only those with SEGMEXEC enabled are affected.

For the workaround in 2.4, open up include/linux/mm.h, find the expand stack 
function.  After the line:
address_m = vma->vm_start + vma->vm_mirror;
add:
if (address_m < address) {
	spin_unlock(&vma->vm_mm->page_table_lock);
	return 0;
}

For the workaround in 2.6.19.2, open up mm/mmap.c, find the expand_stack 
function (not the arch_grows_up version).  After the line:
address_m = vma->vm_start + vma->vm_mirror;
add:
if (address_m < address) {
	anon_vma_unlock(vma);
	return 0;
}

-Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://grsecurity.net/pipermail/grsecurity/attachments/20070120/47fca31f/attachment.pgp 


More information about the grsecurity mailing list