Bug 84728 (CVE-2005-1265) - VUL-0: CVE-2005-1265: kernel mmap DoS, maybe priv escalation
Summary: VUL-0: CVE-2005-1265: kernel mmap DoS, maybe priv escalation
Status: RESOLVED WONTFIX
Alias: CVE-2005-1265
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other All
: P5 - None : Major
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL:
Whiteboard: CVE-2005-1265: CVSS v2 Base Score: 2....
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-20 07:12 UTC by Ludwig Nussel
Modified: 2019-05-21 05:42 UTC (History)
2 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
PoC (833 bytes, text/plain)
2005-05-20 07:15 UTC, Ludwig Nussel
Details
mmap-fix.patch (2.56 KB, patch)
2005-05-30 12:31 UTC, Marcus Meissner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ludwig Nussel 2005-05-20 07:12:19 UTC
We received the following report via vendor-sec.
The issue is public.

Date: Thu, 19 May 2005 18:46:00 -0700
From: Chris Wright <chrisw@osdl.org>
To: vendor-sec@lst.de
Subject: [vendor-sec] [torvalds@osdl.org: Re: [Security] more possible mmap topdown trouble]

When looking at the mmap topdown allocator, I found one could create
illegal maps with vm_start > vm_end (and vm_start in kernel space).
With a large stack rlimit and a large allocation request mmap_base-len
can overflow.  I didn't try to use this for priv. escalation (not sure if
it's possible or not), but I could certainly trigger Oopsen and panics.
Below is the patch Linus is planning on applying, it's generic in
get_unmapped_area to do sanity checking on the return from the arch,
or process, or file specific get_unmapped_area function.  At this point
it's being treated as local DoS.

Here's some examples out mappings I created with the simple attached
program.

$ ./mmap_topdown -l 0x40000000 -s
dff80000-1ff80000 rw-p dff80000 00:00 0
$ ./mmap_topdown -l 0x50000000 -s
cfffa000-1fffa000 rw-p cfffa000 00:00 0
$ ./mmap_topdown -l 0x60000000 -s
bff7e000-1ff7e000 rw-p bff7e000 00:00 0

thanks,
-chris

----- Forwarded message from Linus Torvalds <torvalds@osdl.org> -----

Date: Thu, 19 May 2005 17:38:20 -0700 (PDT)
From: Linus Torvalds <torvalds@osdl.org>
To: Chris Wright <chrisw@osdl.org>
cc: security@kernel.org
Subject: Re: [Security] more possible mmap topdown trouble

On Thu, 19 May 2005, Chris Wright wrote:
> 
> Yeah, sorry, I meant bang on your patch.  So far, so good (in fact the
> small bit above is insufficient because it doesn't catch the general case
> of vm_start > vm_end, whereas your patch does).

Here's an improved version, that allows the "get_area()" function to
return some other error code than just -EINVAL. My original patch would
just always make some get_area() specific error code be converted into
-EINVAL. 

The only difference here is the non-fixed case addition of

	if (addr > (unsigned long)-1000L)
		return addr;

along with the comment that goes with it.

As usual, I'm inclined to apply this fairly soon..

		Linus

----
diff --git a/mm/mmap.c b/mm/mmap.c
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1302,37 +1302,48 @@ unsigned long
 get_unmapped_area(struct file *file, unsigned long addr, unsigned long len,
 		unsigned long pgoff, unsigned long flags)
 {
-	if (flags & MAP_FIXED) {
-		unsigned long ret;
+	unsigned long ret;
 
-		if (addr > TASK_SIZE - len)
-			return -ENOMEM;
-		if (addr & ~PAGE_MASK)
-			return -EINVAL;
-		if (file && is_file_hugepages(file))  {
-			/*
-			 * Check if the given range is hugepage aligned, and
-			 * can be made suitable for hugepages.
-			 */
-			ret = prepare_hugepage_range(addr, len);
-		} else {
-			/*
-			 * Ensure that a normal request is not falling in a
-			 * reserved hugepage range.  For some archs like IA-64,
-			 * there is a separate region for hugepages.
-			 */
-			ret = is_hugepage_only_range(current->mm, addr, len);
-		}
-		if (ret)
-			return -EINVAL;
-		return addr;
-	}
+	if (!(flags & MAP_FIXED)) {
+		unsigned long (*get_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
 
-	if (file && file->f_op && file->f_op->get_unmapped_area)
-		return file->f_op->get_unmapped_area(file, addr, len,
-						pgoff, flags);
+		get_area = current->mm->get_unmapped_area;
+		if (file && file->f_op && file->f_op->get_unmapped_area)
+			get_area = file->f_op->get_unmapped_area;
+		addr = get_area(file, addr, len, pgoff, flags);
 
-	return current->mm->get_unmapped_area(file, addr, len, pgoff, flags);
+		/*
+		 * We allow returning either an error number or an addresses,
+		 * and the "-1000L" magic constant is the same thing we use
+		 * inside err.h: IS_ERR(). We should probably abstract this
+		 * better, especially since some day we may end up having to
+		 * make this architecture-dependent...
+		 */
+		if (addr > (unsigned long)-1000L)
+			return addr;
+	}
+
+	if (addr > TASK_SIZE - len)
+		return -ENOMEM;
+	if (addr & ~PAGE_MASK)
+		return -EINVAL;
+	if (file && is_file_hugepages(file))  {
+		/*
+		 * Check if the given range is hugepage aligned, and
+		 * can be made suitable for hugepages.
+		 */
+		ret = prepare_hugepage_range(addr, len);
+	} else {
+		/*
+		 * Ensure that a normal request is not falling in a
+		 * reserved hugepage range.  For some archs like IA-64,
+		 * there is a separate region for hugepages.
+		 */
+		ret = is_hugepage_only_range(current->mm, addr, len);
+	}
+	if (ret)
+		return -EINVAL;
+	return addr;
 }
 
 EXPORT_SYMBOL(get_unmapped_area);

----- End forwarded message -----
Comment 1 Ludwig Nussel 2005-05-20 07:15:54 UTC
Created attachment 37505 [details]
PoC
Comment 2 Ludwig Nussel 2005-05-20 07:17:46 UTC
According to Greg this is what went into mainline: 
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=07ab67c8d0d7c1021343b7d5c045033d6bf7be69 
 
Don't ask me how to get a useable diff from that though ... 
Comment 3 Sebastian Krahmer 2005-05-23 08:47:05 UTC
> Anyone want to give me a CVE number for this issue, so I can put it in
> the changelog and release notes?

CAN-2005-1265.  Apologies for delay, just catching up with email before my
flight home.

Cheers, Mark
_________________________
Comment 4 Hubert Mantel 2005-05-23 12:52:05 UTC
Can somebody please submit the fix for the problem in a usable form as
attachment to this bug? How severe is this issue? Do we need to address it
immediately? Kernels are already almost scheduled for release...
Comment 5 Marcus Meissner 2005-05-30 12:31:12 UTC
Created attachment 38317 [details]
mmap-fix.patch

extracted from interdiff 2.6.11.10 -> 2.6.11.11
Comment 6 Ludwig Nussel 2005-05-31 12:07:08 UTC
Andrea seems to be the one who can judge if we need it and in which branches. 
Andrea can you please check? 
Comment 7 Marcus Meissner 2005-06-01 08:03:19 UTC
from andrea (on kernel@) 
for whatever reason I can't login on slowzilla right now (bz-login 
stopped working). 
 
The top-down allocator is never on by default AFIK and almost all our 
distro should not have it (i.e. no way to enable it in the old distro). 
I guess only SL93 may require an update. Various apps can break when 
using top-down so its utilization should be discouraged IMHO (RH folks 
thinks different here). 
 
> Do we need to stop the current kernel update to include this or 
> can it wait approx 5 more weeks for the next one? 
 
If it really only affects top-down the severity seems pretty low 
(perhaps Fedora enables it by default and it's more serious for them or 
something like that, but for us the impact should be almost none). Just 
returning to the default boot cmdline will fix it too, which is 
very reasonable short term workaround. 
 
Comment 8 Marcus Meissner 2005-06-01 08:03:59 UTC
from greg: 
 
On Mon, May 30, 2005 at 02:59:58PM +0200, Marcus Meissner wrote: 
> Hi folks, 
> 
> The bugreport: 
>       https://bugzilla.novell.com/show_bug.cgi?id=84728 
> has a denial of service condition in the mmap top-down allocator, 
> fixed in 2.6.11.11. 
 
Do you mean the patch from Linus?  That only fixes a bug that was 
currently in the 2.6.12-rc tree (and could be hit easily there), but 
could not be triggered in the 2.6.11 kernel.  We put it in .11 just to 
make sure. 
 
> As far as I can see it might also have a privilege escalation 
> hidden in there, but I would to poll for your opinion. 
> 
> Can someone enlighten me a bit? 
> 
> Do we need to stop the current kernel update to include this or 
> can it wait approx 5 more weeks for the next one? 
 
I think it can wait. 
 
thanks, 
 
greg k-h 
 
Comment 9 Marcus Meissner 2005-06-01 08:04:16 UTC
from andrea: 
 
Then none of our kernels need updates. I'll check the patch in more 
details to be sure sl9.3 really is safe. For sure older distro can't be 
affected since they've not the top-down thing (we support mapped-base 
feature instead, not in mainline yet and not buggy). 
 
Comment 10 Marcus Meissner 2005-06-01 08:06:26 UTC
from greg: 
 
Here's the patch: 
http://www.kernel.org/git/?p=linux/kernel/git/gregkh/linux-2.6.11.y.git;a=commit 
+;h=27d050adf5cea402a3da5ca7564a23bf87ce7bef 
 
thanks, 
 
greg k-h 
 
(same content like greg already quoted above) 
Comment 11 Marcus Meissner 2005-06-01 08:18:15 UTC
since currently shipping kernels are not affected  i am closing this as 
wontfix. 
Comment 12 Thomas Biege 2009-10-13 21:24:32 UTC
CVE-2005-1265: CVSS v2 Base Score: 2.1 (AV:L/AC:L/Au:N/C:N/I:N/A:P)