Bug 144407 - 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)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jason Baron
: Security
Depends On:
  Show dependency treegraph
Reported: 2005-01-06 14:58 EST by Josh Bressers
Modified: 2013-03-06 00:58 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-21 10:37:27 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 14:58:54 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:20:39 EST
Jim, Jason has already assigned this to himself, but please see
bug 144403 for more details.
Comment 2 Mark J. Cox (Product Security) 2005-01-12 09:40:24 EST
public, removing embargo
Comment 3 Damian Menscher 2005-01-16 11:29:47 EST
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?
Comment 4 Rik van Riel 2005-01-16 13:01:40 EST

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.
Comment 5 Jim Paradis 2005-01-17 15:51:25 EST
A fix for this problem has also been committed to the RHEL2.1 U7
patch pool (in kernel version 2.4.9-e.59)
Comment 6 Josh Bressers 2005-01-21 10:37:27 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.