summaryrefslogtreecommitdiffstats
path: root/mm
diff options
context:
space:
mode:
authorLi Zefan <lizefan@huawei.com>2013-05-09 15:08:15 +0800
committerLinus Torvalds <torvalds@linux-foundation.org>2013-05-09 14:22:47 -0700
commit091d0d55b286c9340201b4ed4470be87fc568228 (patch)
tree5417ab8864fbabe1a9931f3a9a81355cd3d3ebaa /mm
parentde2657f94acd4f0df44626db7c4d2b71babc8cd3 (diff)
downloadlinux-091d0d55b286c9340201b4ed4470be87fc568228.tar.gz
linux-091d0d55b286c9340201b4ed4470be87fc568228.tar.bz2
linux-091d0d55b286c9340201b4ed4470be87fc568228.zip
shm: fix null pointer deref when userspace specifies invalid hugepage size
Dave reported an oops triggered by trinity: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: newseg+0x10d/0x390 PGD cf8c1067 PUD cf8c2067 PMD 0 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 2 PID: 7636 Comm: trinity-child2 Not tainted 3.9.0+#67 ... Call Trace: ipcget+0x182/0x380 SyS_shmget+0x5a/0x60 tracesys+0xdd/0xe2 This bug was introduced by commit af73e4d9506d ("hugetlbfs: fix mmap failure in unaligned size request"). Reported-by: Dave Jones <davej@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Li Zefan <lizfan@huawei.com> Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Acked-by: Rik van Riel <riel@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm')
-rw-r--r--mm/mmap.c8
1 files changed, 6 insertions, 2 deletions
diff --git a/mm/mmap.c b/mm/mmap.c
index 1ae21d645c68..f681e1842fad 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1367,9 +1367,13 @@ SYSCALL_DEFINE6(mmap_pgoff, unsigned long, addr, unsigned long, len,
len = ALIGN(len, huge_page_size(hstate_file(file)));
} else if (flags & MAP_HUGETLB) {
struct user_struct *user = NULL;
+ struct hstate *hs = hstate_sizelog((flags >> MAP_HUGE_SHIFT) &
+ SHM_HUGE_MASK);
- len = ALIGN(len, huge_page_size(hstate_sizelog(
- (flags >> MAP_HUGE_SHIFT) & MAP_HUGE_MASK)));
+ if (!hs)
+ return -EINVAL;
+
+ len = ALIGN(len, huge_page_size(hs));
/*
* VM_NORESERVE is used because the reservations will be
* taken when vm_ops->mmap() is called