Bug 144412 - CAN-2005-0001 page fault @ SMP privilege escalation
Summary: CAN-2005-0001 page fault @ SMP privilege escalation
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Jason Baron
QA Contact: Brian Brock
Whiteboard: embargoed=20050112,impact=important
Depends On:
Blocks: 144195
TreeView+ depends on / blocked
Reported: 2005-01-06 20:05 UTC by Josh Bressers
Modified: 2013-03-06 05:58 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-02-18 17:20:55 UTC
Target Upstream Version:

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

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:092 0 important SHIPPED_LIVE Important: kernel security update 2005-02-18 05:00:00 UTC

Description Josh Bressers 2005-01-06 20:05:48 UTC
*** 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 14:39:34 UTC
public, removing embargo

Comment 3 Dave Jones 2005-01-18 04:21:37 UTC
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-18 04:24:20 UTC
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 19:08:51 UTC
Created attachment 109981 [details]
expand stack race fix

Comment 6 Jason Baron 2005-01-19 19:10:17 UTC
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 07:56:07 UTC
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 17:20:55 UTC
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.