• D
    mm: fix vma_resv_map() NULL pointer · 4523e145
    Dave Hansen 提交于
    hugetlb_reserve_pages() can be used for either normal file-backed
    hugetlbfs mappings, or MAP_HUGETLB.  In the MAP_HUGETLB, semi-anonymous
    mode, there is not a VMA around.  The new call to resv_map_put() assumed
    that there was, and resulted in a NULL pointer dereference:
    
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
      IP: vma_resv_map+0x9/0x30
      PGD 141453067 PUD 1421e1067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      ...
      Pid: 14006, comm: trinity-child6 Not tainted 3.4.0+ #36
      RIP: vma_resv_map+0x9/0x30
      ...
      Process trinity-child6 (pid: 14006, threadinfo ffff8801414e0000, task ffff8801414f26b0)
      Call Trace:
        resv_map_put+0xe/0x40
        hugetlb_reserve_pages+0xa6/0x1d0
        hugetlb_file_setup+0x102/0x2c0
        newseg+0x115/0x360
        ipcget+0x1ce/0x310
        sys_shmget+0x5a/0x60
        system_call_fastpath+0x16/0x1b
    
    This was reported by Dave Jones, but was reproducible with the
    libhugetlbfs test cases, so shame on me for not running them in the
    first place.
    
    With this, the oops is gone, and the output of libhugetlbfs's
    run_tests.py is identical to plain 3.4 again.
    
    [ Marked for stable, since this was introduced by commit c50ac050
      ("hugetlb: fix resv_map leak in error path") which was also marked for
      stable ]
    Reported-by: NDave Jones <davej@redhat.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: <stable@vger.kernel.org>        [2.6.32+]
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    4523e145
hugetlb.c 79.2 KB