*** This bug has been split off bug 144403 *** ------- Original comment by Josh Bressers (Security Response Team) on 2005.01.06 14:56 ------- This has been reported to vendor-sec by Paul Starzetz I have found an exploitable flaw in the page fault handler, however only in the SMP case. The problem is this: [A] down_read(&mm->mmap_sem); vma = find_vma(mm, address); if (!vma) goto bad_area; if (vma->vm_start <= address) goto good_area; if (!(vma->vm_flags & VM_GROWSDOWN)) goto bad_area; if (error_code & 4) { /* * accessing the stack below %esp is always a bug. * The "+ 32" is there due to some instructions (like * pusha) doing post-decrement on the stack and that * doesn't show up until later.. */ if (address + 32 < regs->esp) goto bad_area; } if (expand_stack(vma, address)) [B] goto bad_area; an exploitable race scenario looks as follows: 1) one thread issues down_write on the sem (remap, madvise, ...) 2) two other threads faul below a VM_GROWSDOWN segment (note that they can fault anywhere below vm_start since esp is arbitrary) and sleep in [A] 3) first thread releases the sem and the two others run again, both find the same VMA but: thread1 ----------F1----------[ VMA ] thread2 ---------------F2-----[ VMA ] where F1/2 faul address. If timed carefully we get: thread1 expands stack to F1, installs pte1 thread2 expands stack to F2, installs pte2 resulting in pte1 not covered by the VMA. Techniques like in mremap_pte can be applied to further exploit this condition. Please do not argue that the race window is small - I have seen even smaller windows opening like a barn :-] The critical section is only from [A] to [B], we do not care about timings of handle_mm_fault etc, since the VMA is later consulted only for page flags. Note that this also races with ptrace/proc etc (everything using access_process_vm/get_user_pages).
public, removing embargo http://www.isec.pl/vulnerabilities/isec-0022-pagefault.txt
Created attachment 109912 [details] upstream 2.6.10 patch Here's what got merged upstream, we'll need to modify this somewhat though, as exec-shield plays in the same area.
actually, that's on top of about 4-5 patches in the same area, so it's not particularly helpful without the other bits.
Created attachment 109981 [details] expand stack race fix
The patch from comment #5 is taken from the -ac patch, and should fix this issue. I haven't tested this yet, but Dave mentioned that he had a test program.
I was mistaken. (Getting my isec.pl advisories mixed up) I don't have a test for this issue.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-092.html