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

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

Attachments (Terms of Use)
upstream 2.6.10 patch (2.53 KB, patch)
2005-01-17 23:21 EST, Dave Jones
no flags Details | Diff
expand stack race fix (696 bytes, text/plain)
2005-01-19 14:08 EST, Jason Baron
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:092 important SHIPPED_LIVE Important: kernel security update 2005-02-18 00:00:00 EST

  None (edit)
Description Josh Bressers 2005-01-06 15:05:48 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 2 Mark J. Cox 2005-01-12 09:39:34 EST
public, removing embargo
Comment 3 Dave Jones 2005-01-17 23:21:37 EST
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.
Comment 4 Dave Jones 2005-01-17 23:24:20 EST
actually, that's on top of about 4-5 patches in the same area, so it's not
particularly helpful without the other bits.
Comment 5 Jason Baron 2005-01-19 14:08:51 EST
Created attachment 109981 [details]
expand stack race fix
Comment 6 Jason Baron 2005-01-19 14:10:17 EST
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.

Comment 7 Dave Jones 2005-01-25 02:56:07 EST
I was mistaken. (Getting my isec.pl advisories mixed up) I don't have a test for
this issue.
Comment 9 Josh Bressers 2005-02-18 12:20:55 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.