[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