public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Tavis Ormandy <taviso@cmpxchg8b.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
	security@kernel.org, kees@ubuntu.com, Greg KH <gregkh@suse.de>,
	linux-kernel@vger.kernel.org, eugene@redhat.com,
	Linus Torvalds <torvalds@linux-foundation.org>,
	stable@kernel.org
Subject: Re: [Security] [PATCH] install_special_mapping skips security_file_mmap check.
Date: Thu, 9 Dec 2010 12:28:02 -0800	[thread overview]
Message-ID: <20101209122802.939938ca.akpm@linux-foundation.org> (raw)
In-Reply-To: <20101209191637.GD9267@cmpxchg8b.com>

On Thu, 9 Dec 2010 20:16:37 +0100
Tavis Ormandy <taviso@cmpxchg8b.com> wrote:

> On Thu, Dec 09, 2010 at 10:38:53AM -0800, Randy Dunlap wrote:
> > 
> > Uh, something happened to the tabs at the beginning of each line...
> > I.e., the original file content has been mucked up.
> > 
> 
> Gah. Apologies, second attempt...
> 
> The install_special_mapping routine (used, for example, to setup the vdso)
> skips the security check before insert_vm_struct, allowing a local attacker to
> bypass the mmap_min_addr security restriction by limiting the available pages
> for special mappings. bprm_mm_init() also skips the check, although I don't
> think this can be used to bypass any restrictions, I don't see any reason not
> to have the security check.
> 
> $ uname -m
> x86_64
> $ cat /proc/sys/vm/mmap_min_addr
> 65536
> $ cat install_special_mapping.s
> section .bss
>     resb BSS_SIZE
> section .text
>     global _start
>     _start:
>         mov     eax, __NR_pause
>         int     0x80
> $ nasm -D__NR_pause=29 -DBSS_SIZE=0xfffed000 -f elf -o install_special_mapping.o install_special_mapping.s
> $ ld -m elf_i386 -Ttext=0x10000 -Tbss=0x11000 -o install_special_mapping install_special_mapping.o
> $ ./install_special_mapping &
> [1] 14303
> $ cat /proc/14303/maps 
> 0000f000-00010000 r-xp 00000000 00:00 0                                  [vdso]
> 00010000-00011000 r-xp 00001000 00:19 2453665                            /home/taviso/install_special_mapping
> 00011000-ffffe000 rwxp 00000000 00:00 0                                  [stack]
> 
> It's worth noting that Red Hat are shipping with mmap_min_addr set to 4096.
> 
> ...
>
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2479,6 +2479,11 @@ int install_special_mapping(struct mm_struct *mm,
>  	vma->vm_ops = &special_mapping_vmops;
>  	vma->vm_private_data = pages;
>  
> +	if (security_file_mmap(NULL, 0, 0, 0, vma->vm_start, 1)) {
> +		kmem_cache_free(vm_area_cachep, vma);
> +		return -EPERM;
> +	}

This should return the security_file_mmap() errno rather than assuming
EPERM.  Although it happens to be the case that EPERM is the only errno
which security_file_mmap() presently returns, afacit.

Ditto insert_vm_struct(), with s/EPERM/ENOMEM/

Please review and test?


--- a/mm/mmap.c~mm-install_special_mapping-skips-security_file_mmap-check-fix
+++ a/mm/mmap.c
@@ -2463,6 +2463,7 @@ int install_special_mapping(struct mm_st
 			    unsigned long vm_flags, struct page **pages)
 {
 	struct vm_area_struct *vma;
+	int ret;
 
 	vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
 	if (unlikely(vma == NULL))
@@ -2479,21 +2480,21 @@ int install_special_mapping(struct mm_st
 	vma->vm_ops = &special_mapping_vmops;
 	vma->vm_private_data = pages;
 
-	if (security_file_mmap(NULL, 0, 0, 0, vma->vm_start, 1)) {
-		kmem_cache_free(vm_area_cachep, vma);
-		return -EPERM;
-	}
-
-	if (unlikely(insert_vm_struct(mm, vma))) {
-		kmem_cache_free(vm_area_cachep, vma);
-		return -ENOMEM;
-	}
+	ret = security_file_mmap(NULL, 0, 0, 0, vma->vm_start, 1);
+	if (ret < 0)
+		goto out;
+
+	ret = insert_vm_struct(mm, vma);
+	if (ret < 0)
+		goto out;
 
 	mm->total_vm += len >> PAGE_SHIFT;
 
 	perf_event_mmap(vma);
-
 	return 0;
+out:
+	kmem_cache_free(vm_area_cachep, vma);
+	return ret;
 }
 
 static DEFINE_MUTEX(mm_all_locks_mutex);
_


  reply	other threads:[~2010-12-09 20:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-09 14:29 [PATCH] install_special_mapping skips security_file_mmap check Tavis Ormandy
2010-12-09 18:38 ` Randy Dunlap
2010-12-09 19:16   ` Tavis Ormandy
2010-12-09 20:28     ` Andrew Morton [this message]
2010-12-09 21:43       ` [Security] " James Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101209122802.939938ca.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=eugene@redhat.com \
    --cc=gregkh@suse.de \
    --cc=kees@ubuntu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.com \
    --cc=security@kernel.org \
    --cc=stable@kernel.org \
    --cc=taviso@cmpxchg8b.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox