Bug 144410 - CAN-2005-0001 page fault @ SMP privilege escalation
CAN-2005-0001 page fault @ SMP privilege escalation
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
: Security
Depends On:
  Show dependency treegraph
Reported: 2005-01-06 15:03 EST by Josh Bressers
Modified: 2015-01-04 17:15 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-24 02:14:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Josh Bressers 2005-01-06 15:03:47 EST
*** 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

Note that this also races with ptrace/proc etc (everything using
Comment 1 Josh Bressers 2005-01-06 15:04:22 EST
This issue should also affect FC2.
Comment 2 Mark J. Cox (Product Security) 2005-01-12 09:42:03 EST
Public, removing embargo
Comment 3 Dave Jones 2005-02-24 02:14:09 EST
fixed in 1.741_FC3 | 1.9_FC2

Note You need to log in before you can comment on or make changes to this bug.