Bug 144408 - CAN-2005-0001 page fault @ SMP privilege escalation
CAN-2005-0001 page fault @ SMP privilege escalation
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel (Show other bugs)
ia64 Linux
medium Severity high
: ---
: ---
Assigned To: Jason Baron
Brian Brock
: Security
Depends On:
  Show dependency treegraph
Reported: 2005-01-06 15:01 EST by Josh Bressers
Modified: 2013-03-06 00:58 EST (History)
6 users (show)

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

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:017 normal SHIPPED_LIVE Important: kernel security update 2005-01-21 00:00:00 EST

  None (edit)
Description Josh Bressers 2005-01-06 15:01:33 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 Ernie Petrides 2005-01-06 18:22:16 EST
Jim, Jason has already assigned this to himself, but please see
bug 144403 for more details.
Comment 2 Mark J. Cox 2005-01-12 09:41:22 EST
Public, removing embargo
Comment 3 Jim Paradis 2005-01-17 15:57:22 EST
A fix for this problem has also been committed to the RHEL2.1 U7
patch pool (in kernel version 2.4.18-e.53)
Comment 4 Josh Bressers 2005-01-21 10:41:21 EST
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.


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