A new mremap() vulnerability

The mremap() system call allows a process to change its virtual memory layout by adjusting the size and location of a virtual memory area. One of the things mremap() can do is move one virtual memory area (VMA) into the middle of another one. In that case, the target VMA will be split in two so that the space in the middle can be freed and reused for the VMA being moved. As long as the calling process knows what it is doing (it doesn't need the pages being replaced by the moved area, for example), all of this is fine.

An interesting thing can happen in the 2.4.24 and 2.6.2 kernels, however. The kernel enforces a limit on the maximum number of VMAs that any one process can have. If the kernel attempts to split a VMA in response to the sort of mremap() call described above, it will check the process's VMA usage against the limit. Splitting requires the addition of a new VMA, so this check is necessary. If the limit has been reached, the internal call which splits the VMA (do_munmap()) will return a failure status. So far, so good.

The problem is that mremap() did not check to see if do_munmap() succeeded or not. If the split failed, mremap() would continue anyway. The end result is that the old target VMA would remain, with its existing permissions, but some of its associated page table entries would be overwritten by entries from the VMA being moved. In other words, an attacker can exploit this bug to obtain access to a set of pages which the kernel would not otherwise have allowed. This vulnerability can be exploited by a local hacker to obtain root access on any Linux system running a vulnerable kernel.

The solution is to upgrade to 2.4.25 or 2.6.3, or to apply the appropriate distributor security update. The LWN vulnerability entry tracks the available updates. For more information on the vulnerability, see this advisory from Paul Starzetz.

Index entries for this article
Kernel	Security/Vulnerabilities

---

to post comments

Isn't 2.4.25 vulnerable?

Posted Feb 19, 2004 4:58 UTC (Thu) by walters (subscriber, #7396) [Link] (2 responses)

The advisory says 2.4.25 is vulnerable.

It's 2.2.25

Posted Feb 19, 2004 5:14 UTC (Thu) by proski (guest, #104) [Link] (1 responses)

No, it doesn't. Search for "2.4.25" in the text. If your browser doesn't have that function, install one that has it. "2.4.25" is not in the text. It takes at most three seconds to check. You would still get the first post even if you checked your facts.

And by the way, real programmers don't trust their eyes and fingers. "2.2.25" may look similar to "2.4.25" for you, but not for the browser.

It's 2.2.25

Posted Feb 19, 2004 8:19 UTC (Thu) by walters (subscriber, #7396) [Link]

Thanks, you're right. I honestly had completely forgotten about 2.2.x :)

A new mremap() vulnerability

Posted Feb 19, 2004 13:05 UTC (Thu) by gerv (guest, #3376) [Link]

An interesting thing can happen in the 2.4.24 and 2.6.2 kernels, however.

This sentence rather implies that it's only these two kernels. In fact, it's all existing kernels from 2.2 upwards apart from 2.4.25 and 2.6.3.

Gerv

A new mremap() vulnerability

Posted Feb 19, 2004 16:53 UTC (Thu) by nick.leroy (guest, #109) [Link]

SuSE has an update:

SUSE Security Announcement: Linux Kernel (SuSE-SA:2004:005)

A new mremap() vulnerability

Posted Feb 24, 2004 2:14 UTC (Tue) by stock (guest, #5849) [Link]

"The solution is to upgrade to 2.4.25 or 2.6.3, or to apply the appropriate distributor security update."

All we need is the patch concerning this vulnerability. Sofar after hunting down the Bugtraq list, i couldn't find anything except vendor related "patches" in the form of complete kernel updates or in the form of binary patches. Some vendors created a new source tree, but that contains their complete backlog of other patches.

So where is the source to that patch? I would like to patch my older kernel with it.

Where is the Open Source Patch to this vulnerability?

Robert