*** 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).
Jim, Jason has already assigned this to himself, but please see bug 144403 for more details.
http://www.isec.pl/vulnerabilities/isec-0022-pagefault.txt public, removing embargo
Does this affect RHEL3? I don't see a bug tracking it. Bug 144403 is still embargoed... is there a reason? This has been public for 4 days. Is a patch coming?
Damian, RHEL3 is not affected. The bug was fixed in RHEL3 some time ago, however at the time we did not realise its security concerns - it was assessed to be a very low probability data corrupter, only triggerable by the process that could corrupt its own data. Also, I think RHEL3 does not have the pgd cache, which also makes the security problem go away.
A fix for this problem has also been committed to the RHEL2.1 U7 patch pool (in kernel version 2.4.9-e.59)
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-016.html