[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20101209122802.939938ca.akpm@linux-foundation.org>
Date: Thu, 9 Dec 2010 12:28:02 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Tavis Ormandy <taviso@...xchg8b.com>
Cc: Randy Dunlap <randy.dunlap@...cle.com>, security@...nel.org,
kees@...ntu.com, Greg KH <gregkh@...e.de>,
linux-kernel@...r.kernel.org, eugene@...hat.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
stable@...nel.org
Subject: Re: [Security] [PATCH] install_special_mapping skips
security_file_mmap check.
On Thu, 9 Dec 2010 20:16:37 +0100
Tavis Ormandy <taviso@...xchg8b.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);
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists