1 From 4523e1458566a0e8ecfaff90f380dd23acc44d27 Mon Sep 17 00:00:00 2001
2 From: Dave Hansen <dave@linux.vnet.ibm.com>
3 Date: Wed, 30 May 2012 07:51:07 -0700
4 Subject: mm: fix vma_resv_map() NULL pointer
6 From: Dave Hansen <dave@linux.vnet.ibm.com>
8 commit 4523e1458566a0e8ecfaff90f380dd23acc44d27 upstream.
10 hugetlb_reserve_pages() can be used for either normal file-backed
11 hugetlbfs mappings, or MAP_HUGETLB. In the MAP_HUGETLB, semi-anonymous
12 mode, there is not a VMA around. The new call to resv_map_put() assumed
13 that there was, and resulted in a NULL pointer dereference:
15 BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
16 IP: vma_resv_map+0x9/0x30
17 PGD 141453067 PUD 1421e1067 PMD 0
18 Oops: 0000 [#1] PREEMPT SMP
20 Pid: 14006, comm: trinity-child6 Not tainted 3.4.0+ #36
21 RIP: vma_resv_map+0x9/0x30
23 Process trinity-child6 (pid: 14006, threadinfo ffff8801414e0000, task ffff8801414f26b0)
26 hugetlb_reserve_pages+0xa6/0x1d0
27 hugetlb_file_setup+0x102/0x2c0
31 system_call_fastpath+0x16/0x1b
33 This was reported by Dave Jones, but was reproducible with the
34 libhugetlbfs test cases, so shame on me for not running them in the
37 With this, the oops is gone, and the output of libhugetlbfs's
38 run_tests.py is identical to plain 3.4 again.
40 [ Marked for stable, since this was introduced by commit c50ac050811d
41 ("hugetlb: fix resv_map leak in error path") which was also marked for
44 Reported-by: Dave Jones <davej@redhat.com>
45 Cc: Mel Gorman <mel@csn.ul.ie>
46 Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
47 Cc: Christoph Lameter <cl@linux.com>
48 Cc: Andrea Arcangeli <aarcange@redhat.com>
49 Cc: Andrew Morton <akpm@linux-foundation.org>
50 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
51 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
55 1 file changed, 2 insertions(+), 1 deletion(-)
59 @@ -3035,7 +3035,8 @@ int hugetlb_reserve_pages(struct inode *
60 region_add(&inode->i_mapping->private_list, from, to);