Help answer threads with 0 replies.
Go Back > Forums > Linux Forums > Linux - Security
User Name
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.


  Search this Thread
Old 02-18-2004, 11:34 AM   #1
Registered: Jun 2002
Location: USA
Distribution: Suse 8.0
Posts: 247

Rep: Reputation: 30
Second mremap critical bug

i would have only posted url but it seems to be broken

Synopsis: Linux kernel do_mremap VMA limit local privilege escalation
Product: Linux kernel
Version: 2.2 up to 2.2.25, 2.4 up to 2.4.24, 2.6 up to 2.6.2
CVE: CAN-2004-0077
Author: Paul Starzetz <>
Date: February 18, 2004


A critical security vulnerability has been found in the Linux kernel
memory management code inside the mremap(2) system call due to missing
function return value check. This bug is completely unrelated to the
mremap bug disclosed on 05-01-2004 except concerning the same internal
kernel function code.


The Linux kernel manages a list of user addressable valid memory
locations on a per process basis. Every process owns a single linked
list of so called virtual memory area descriptors (called from now on
just VMAs). Every VMA describes the start of a valid memory region, its
length and moreover various memory flags like page protection.

Every VMA in the list corresponds to a part of the process's page table.
The page table contains descriptors (in short page table entries PTEs)
of physical memory pages seen by the process. The VMA descriptor can be
thus understood as a high level description of a particular region of
the process's page table storing PTE properties like page R/W flag and
so on.

The mremap() system call provides resizing (shrinking or growing) as
well as moving of existing virtual memory areas or any of its parts
across process's addressable space.

Moving a part of the virtual memory from inside a VMA area to a new
location requires creation of a new VMA descriptor as well as copying
the underlying page table entries described by the VMA from the old to
the new location in the process's page table.

To accomplish this task the do_mremap code calls the do_munmap()
internal kernel function to remove any potentially existing old memory
mapping in the new location as well as to remove the old virtual memory
mapping. Unfortunately the code doesn't test the return value of the
do_munmap() function which may fail if the maximum number of available
VMA descriptors has been exceeded. This happens if one tries to unmap
middle part of an existing memory mapping and the process's limit on the
number of VMAs has been reached (which is currently 65535).

One of the possible situations can be illustrated with the following
picture. The corresponding page table entries (PTEs) have been marked
with o and x:

Before mremap():

(oooooooooooooooooooooooo) (xxxxxxxxxxxx)
[----------VMA1----------] [----VMA2----]
[REMAPPED-VMA] <---------------|

After mremap() without VMA limit:


After mremap() but VMA limit:


After the maximum number of VMAs in the process's VMA list has been
reached do_munmap() will refuse to create the necessary VMA hole because
it would split the original VMA in two disjoint VMA areas exceeding the
VMA descriptor limit.

Due to the missing return value check after trying to unmap the middle
of the VMA1 (this is the first invocation of do_munmap inside do_mremap
code) the corresponding page table entries from VMA2 are still inserted
into the page table location described by VMA1 thus being subject to
VMA1 page protection flags. It must be also mentioned that the original
PTEs in the VMA1 are lost thus leaving the corresponding page frames
unusable for ever.

The kernel also tries to insert the overlapping VMA area into the VMA
descriptor list but this fails due to further checks in the low level
VMA manipulation code. The low level VMA list check in the 2.4 and 2.6
kernel versions just call BUG() therefore terminating the malicious

There are also two other unchecked calls to do_munmap() inside the
do_mremap() code and we believe that the second occurrence of unchecked
do_munmap is also exploitable. The second occurrence takes place if the
VMA to be remapped is beeing truncated in place. Note that do_munmap can
also fail on an exceptional low memory condition while trying to
allocate a VMA descriptor.

We were able to create a robust proof-of-concept exploit code giving
full super-user privileges on all vulnerable kernel versions. The
exploit code will be released next week.


Since no special privileges are required to use the mremap(2) system
call any process may use its unexpected behavior to disrupt the kernel
memory management subsystem.

Proper exploitation of this vulnerability leads to local privilege
escalation giving an attacker full super-user privileges. The
vulnerability may also lead to a denial-of-service attack on the
available system memory.

Tested and known to be vulnerable kernel versions are all <= 2.2.25, <=
2.4.24 and <= 2.6.1. The 2.2.25 version of Linux kernel does not
recognize the MREMAP_FIXED flag but this does not prevent the bug from
being successfully exploited. All users are encouraged to patch all
vulnerable systems as soon as appropriate vendor patches are released.
There is no hotfix for this vulnerablity. Limited per user virtual
memory still permits do_munmap() to fail.


Paul Starzetz <> has identified the vulnerability and
Old 02-18-2004, 02:10 PM   #2
Registered: May 2001
Posts: 29,393
Blog Entries: 55

Rep: Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565
...just saw the first POC on some mailinglist.

On Bugtraq Steve Bremer writes: "I think it's worth noting that those who have been using either the 2.4.23-ow2 or the 2.4.24-ow1 kernel patches from the Openwall Project are not vulnerable to this latest mremap() bug."
[edit /]

...just saw the first POC on some mailinglist.
Grsecurity-1.9.13 reinforced 2.4.24:
]$ gcc -W -Wall mremap2_poc.c && ./a.out
mmap: Cannot allocate memory
created ~43577 VMAs
kernel may not be vulnerable

Someone else care to confirm Grsec results?

Last edited by unSpawn; 02-18-2004 at 05:08 PM.
Old 02-18-2004, 07:44 PM   #3
Registered: Jul 2003
Location: Dallas, TX
Distribution: Ubuntu 10.04 LTS
Posts: 987

Rep: Reputation: 30
so the 2.6.3 and 2.4.25 kernels contain the fix for this vulnerability?
Old 02-18-2004, 09:58 PM   #4
Registered: Jun 2002
Location: USA
Distribution: Suse 8.0
Posts: 247

Original Poster
Rep: Reputation: 30
Slack 9.1

Linux kernel 2.4.22

# ./a.out
mmap: Cannot allocate memory
created ~65530 VMAs
now mremapping 0x3FFE5000 at 0x3FFE1000
Segmentation fault
Old 02-18-2004, 10:10 PM   #5
Registered: Feb 2004
Posts: 30

Rep: Reputation: 15
I'm not clear on this. Does this or does this not affect kernel 2.6.2???

Old 02-18-2004, 10:38 PM   #6
Registered: Jun 2003
Location: Hanover, New Hampshire, USA
Distribution: Debian Sid (Unstable)
Posts: 143

Rep: Reputation: 15
Yes, it affects 2.6.2. It's fixed in 2.6.3.
Old 02-19-2004, 09:45 AM   #7
Registered: Sep 2003
Location: USA & Canada
Distribution: Slackware 12.0
Posts: 978

Rep: Reputation: 30
Originally posted by smith847be
Yes, it affects 2.6.2. It's fixed in 2.6.3.
does this affect 2.4.2 and/or should i wait for mandrake to come out with a patch....?

- perry
Old 02-19-2004, 02:24 PM   #8
Registered: Jul 2003
Location: Toronto, Canada
Distribution: Debian etch, Gentoo
Posts: 312

Rep: Reputation: 30
From the 2.4.25-final changelog:

Andrea Arcangeli:
o Return proper do_munmap() error code

I assume this is the fix described above? if so the latest 2.4 on is patched against it. Someone pls. correct me if I'm wrong, I'm not a big fan of false information

Old 02-20-2004, 10:57 AM   #9
Registered: Sep 2003
Location: /dev/null
Distribution: FreeBSD 5.4, OpenBSD 3.7
Posts: 95

Rep: Reputation: 15
Here's a link for it..


Old 02-20-2004, 06:02 PM   #10
Senior Member
Registered: Apr 2003
Location: Minnesota, USA
Distribution: Slack 10.0 w/2.4.26
Posts: 1,032

Rep: Reputation: 45
Originally posted by smith847be
Yes, it affects 2.6.2. It's fixed in 2.6.3.
Damn it! I just got my Nvidia driver working on 2.6.2!
Old 02-20-2004, 11:01 PM   #11
LQ Newbie
Registered: Dec 2003
Location: Northern Colorado
Distribution: slack 9.1 replacing mandrake 9.2
Posts: 23

Rep: Reputation: 15
One of the articles I read said this vulnerability could not be exploited remotely. Does this mean that I probably don't need to worry about patching asap for my home computer?
- Joel
Old 02-21-2004, 01:14 PM   #12
Registered: Jan 2004
Distribution: FreeBSD, Slackware
Posts: 121

Rep: Reputation: 15
IS there a kernel patch for 2.4.21, because I have to have a kernel 2.4.21 or before to use the realtek drivers for my wireless lan!
Old 02-21-2004, 03:40 PM   #13
Registered: Jun 2001
Location: Up in the clouds
Distribution: Fedora et al.
Posts: 353

Rep: Reputation: 30
I can't find an update for this anywhere from RedHat, does anybody know if the RedHat 7 kernels are vulnerable. I am running 2.4.20-28.7, RH 7.3 and redhat doesn't say that it is affected by this, but doesn't say it isn't. Any ideas? I know that it says that all version <= 2.4.24 are vulnerable, but RedHat has a tendency to use different package naming according to their own fixes. TIA!

Old 02-22-2004, 05:38 AM   #14
Registered: Feb 2004
Location: United States
Distribution: Ubuntu 10.10
Posts: 319

Rep: Reputation: 30
I have downloaded the patch from, specifically patch-2.6.3.bz2.
I am new to linux and do not know what to do to update the kernel. My distribution is JDS (based on SuSE 8.1 and Linux 2.4.19).
Old 02-22-2004, 09:06 PM   #15
Senior Member
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 69
Originally posted by mikeyt_333
I can't find an update for this anywhere from RedHat, does anybody know if the RedHat 7 kernels are vulnerable. I am running 2.4.20-28.7, RH 7.3 and redhat doesn't say that it is affected by this, but doesn't say it isn't. Any ideas? I know that it says that all version <= 2.4.24 are vulnerable, but RedHat has a tendency to use different package naming according to their own fixes. TIA!

Redhat stopped support for all Redhat releases except RH9 and the Enterprise Editions, so you won't find updates for any of those editions you listed. They did release a new kernel for RH9 and you can find the vulnerability info here. It does say all kernels 2.4.24 and prior. So update you kernel.

As a side note, you should really upgrade your distro as you won't be able to get official updates from Redhat anymore. While it's not that pressing right now, you could be in for a real world of hurt when the next remote exploit comes out.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Free86 bug or nVidia bug?? ProtoformX Linux - Software 2 05-12-2004 03:38 AM
When will the mremap() kernel bug get patched? KingofBLASH Slackware 4 03-08-2004 06:53 PM
Yet another mremap critical flaw? chort Linux - Security 5 03-08-2004 02:31 PM
should I be worried about the Second mremap critical bug? Mandrake 9.2 user Fear58 Linux - Security 3 02-21-2004 01:42 PM
Help! Critical slovin Linux - General 7 05-07-2002 05:23 AM > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 02:51 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration