The mremap system call provides functionality of resizing (shrinking or growing) as well as moving across process's addressable space of existing 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 parts of the kernel memory management subroutines finally leading to unexpected behavior.
The broken VMA in the above example has been marked with a [*].
Impact:
Since no special privileges are required to use the mremap(2) system call any process may misuse its unexpected behavior to disrupt the kernel memory management subsystem. Proper exploitation of this vulnerability may lead to local privilege escalation including execution of arbitrary code with kernel level access. Proof-of-concept exploit code has been created and successfully tested giving UID 0 shell on vulnerable systems.
The exploitability of the discovered vulnerability is possible, although not a trivial one. Paul has identified at least two different attack vectors for the 2.4 kernel series. All users are encouraged to patch all vulnerable systems as soon as appropriate vendor patches are released.
