Synopsis: Linux kernel do_mremap VMA limit local privilege escalation vulnerability 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 Vendor: http://www.kernel.org/ URL: http://isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt CVE: CAN-2004-0077 Author: Paul Starzetz <ihaquer@isec.pl> 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. Reproducible: Always Steps to Reproduce:
hm... kernel.org got some problems: "Load Average: 134.10 127.67 126.22 (1229 processes)" anyone got the patch for 2.4? :)
got it: diff -urN linux-2.4.24/mm/mremap.c linux-2.4.25/mm/mremap.c --- linux-2.4.24/mm/mremap.c 2004-01-05 05:53:56.000000000 -0800 +++ linux-2.4.25/mm/mremap.c 2004-02-18 05:36:32.000000000 -0800 @@ -258,16 +258,20 @@ if ((addr <= new_addr) && (addr+old_len) > new_addr) goto out; - do_munmap(current->mm, new_addr, new_len); + ret = do_munmap(current->mm, new_addr, new_len); + if (ret && new_len) + goto out; } /* * Always allow a shrinking remap: that just unmaps * the unnecessary pages.. */ - ret = addr; if (old_len >= new_len) { - do_munmap(current->mm, addr+new_len, old_len - new_len); + ret = do_munmap(current->mm, addr+new_len, old_len - new_len); + if (ret && old_len != new_len) + goto out; + ret = addr; if (!(flags & MREMAP_FIXED) || (new_addr == addr)) goto out; } fixed by hand in gentoo-sources-2.4.20-r10
fix for gentoo-sources-2.4.20-r10: --- mremap.c~ 2004-01-06 20:08:57.000000000 +0100 +++ mremap.c 2004-02-18 18:00:42.000000000 +0100 @@ -316,7 +316,9 @@ if ((addr <= new_addr) && (addr+old_len) > new_addr) goto out; - do_munmap(current->mm, new_addr, new_len); + ret = do_munmap(current->mm, new_addr, new_len); + if (ret && new_len) + goto out; } /* @@ -324,9 +326,11 @@ * the unnecessary pages.. * do_munmap does all the needed commit accounting */ - ret = addr; if (old_len >= new_len) { - do_munmap(current->mm, addr+new_len, old_len - new_len); + ret = do_munmap(current->mm, addr+new_len, old_len - new_len); + if (ret && old_len != new_len) + goto out; + ret = addr; if (!(flags & MREMAP_FIXED) || (new_addr == addr)) goto out; old_len = new_len;
There is a discrepancy between the kernel versions listed in the isec.pl link and the bugtraq list posting, in particular the version of kernel that is vulnerable in the 2.6 series. The bugtraq post by Paul Starzetz has: "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 says <= 2.6.1. The isec link has: "Tested and known to be vulnerable kernel versions are all <= 2.2.25, <= 2.4.24 and <= 2.6.2. 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." <= 2.6.2. Anyone able to confirm one or the other?
Link for the bugtraq post: http://securityfocus.com/archive/1/354284/2004-02-15/2004-02-21/0
*** This bug has been marked as a duplicate of 42024 ***
Ignore me. Just got an email back from Paul and the web page version is the most up to date (ie: <= 2.6.2)