Linux Kernel mremap() Improper Bounds Checking Lets Local Users Gain Root Privileges
SecurityTracker Alert ID: 1008593|
SecurityTracker URL: http://securitytracker.com/id/1008593
(Links to External Site)
Updated: Jan 6 2004|
Original Entry Date: Jan 5 2004
Denial of service via local system, Execution of arbitrary code via local system, Root access via local system|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): 2.4.x, 2.6.x|
A vulnerability was reported in the Linux kernel do_mremap() function. A local user can gain elevated privileges.|
Paul Starzetz and Wojciech Purczynski of iSEC Security Research reported that the mremap(2) system call does not perform proper bounds checking in the do_mremap() kernel code. A local user can reportedly cause the kernel to remap memory and create a virtual memory area that is 0 bytes in length.
According to the report, a local user can gain root privileges on the system through non-trivial exploit methods.
The original advisory is available at:
A local user can execute arbitrary code with root privileges. A local user can also cause denial of service conditions on the system.|
Fixes are reportedly available (or pending) for various Linux kernel distributions. As the distributors release their fixes, separate Alerts will be issued [see the Message History].|
Vendor URL: www.kernel.org/ (Links to External Site)
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Subject: [Full-Disclosure] Linux kernel mremap vulnerability|
-----BEGIN PGP SIGNED MESSAGE-----
Synopsis: Linux kernel do_mremap local privilege escalation vulnerability
Product: Linux kernel
Version: 2.2, 2.4 and 2.6 series
Author: Paul Starzetz <firstname.lastname@example.org>, Wojciech Purczynski
Date: January 5, 2004
A critical security vulnerability has been found in the Linux kernel
memory management code in mremap(2) system call due to incorrect bound
The mremap system call provides functionality of resizing (shrinking or
ing virtual memory areas (VMAs) or any of its parts.
A typical VMA covers at least one memory page (which is exactly 4kB on
the i386 architecture). An incorrect bound check discovered inside the
do_mremap() kernel code performing remapping of a virtual memory area
may lead to creation of a virtual memory area of 0 bytes length.
The problem bases on the general mremap flaw that remapping of 2 pages
from inside a VMA creates a memory hole of only one page in length but
an additional VMA of two pages. In the case of a zero sized remapping
request no VMA hole is created but an additional VMA descriptor of 0
bytes in length is created.
Such a malicious virtual memory area may disrupt the operation of other
A typical process's memory layout showing invalid VMA created with
mremap system call:
08048000-0804c000 r-xp 00000000 03:05 959142 /tmp/test
0804c000-0804d000 rw-p 00003000 03:05 959142 /tmp/test
0804d000-0804e000 rwxp 00000000 00:00 0
40000000-40014000 r-xp 00000000 03:05 1544523 /lib/ld-2.3.2.so
40014000-40015000 rw-p 00013000 03:05 1544523 /lib/ld-2.3.2.so
40015000-40016000 rw-p 00000000 00:00 0
4002c000-40158000 r-xp 00000000 03:05 1544529 /lib/libc.so.6
40158000-4015d000 rw-p 0012b000 03:05 1544529 /lib/libc.so.6
4015d000-4015f000 rw-p 00000000 00:00 0
[*] 60000000-60000000 rwxp 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0
The broken VMA in the above example has been marked with a [*].
Since no special privileges are required to use the mremap(2) system
trary code with kernel level access. Proof-of-concept exploit code has
been created and successfully tested giving UID 0 shell on vulnerable
The exploitability of the discovered vulnerability is possible, although
tors for the 2.4 kernel series. All users are encouraged to patch all
vulnerable systems as soon as appropriate vendor patches are released.
Paul Starzetz <email@example.com> has identified the vulnerability and
performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.
This document and all the information it contains are provided "as is",
press or implied.
The authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of the information provided in
this document. Liability claims regarding damage caused by the use of
complete or incorrect, will therefore be rejected.
iSEC Security Research
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----
Full-Disclosure - We believe in it.