• Greg Pearson's avatar
    vmcore: prevent PT_NOTE p_memsz overflow during header update · 38dfac84
    Greg Pearson authored
    Currently, update_note_header_size_elf64() and
    update_note_header_size_elf32() will add the size of a PT_NOTE entry to
    real_sz even if that causes real_sz to exceeds max_sz.  This patch
    corrects the while loop logic in those routines to ensure that does not
    happen and prints a warning if a PT_NOTE entry is dropped.  If zero
    PT_NOTE entries are found or this condition is encountered because the
    only entry was dropped, a warning is printed and an error is returned.
    
    One possible negative side effect of exceeding the max_sz limit is an
    allocation failure in merge_note_headers_elf64() or
    merge_note_headers_elf32() which would produce console output such as
    the following while booting the crash kernel.
    
      vmalloc: allocation failure: 14076997632 bytes
      swapper/0: page allocation failure: order:0, mode:0x80d2
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-gbp1 #7
      Call Trace:
        dump_stack+0x19/0x1b
        warn_alloc_failed+0xf0/0x160
        __vmalloc_node_range+0x19e/0x250
        vmalloc_user+0x4c/0x70
        merge_note_headers_elf64.constprop.9+0x116/0x24a
        vmcore_init+0x2d4/0x76c
        do_one_initcall+0xe2/0x190
        kernel_init_freeable+0x17c/0x207
        kernel_init+0xe/0x180
        ret_from_fork+0x7c/0xb0
    
      Kdump: vmcore not initialized
    
      kdump: dump target is /dev/sda4
      kdump: saving to /sysroot//var/crash/127.0.0.1-2014.01.28-13:58:52/
      kdump: saving vmcore-dmesg.txt
      Cannot open /proc/vmcore: No such file or directory
      kdump: saving vmcore-dmesg.txt failed
      kdump: saving vmcore
      kdump: saving vmcore failed
    
    This type of failure has been seen on a four socket prototype system
    with certain memory configurations.  Most PT_NOTE sections have a single
    entry similar to:
    
      n_namesz = 0x5
      n_descsz = 0x150
      n_type   = 0x1
    
    Occasionally, a second entry is encountered with very large n_namesz and
    n_descsz sizes:
    
      n_namesz = 0x80000008
      n_descsz = 0x510ae163
      n_type   = 0x80000008
    
    Not yet sure of the source of these extra entries, they seem bogus, but
    they shouldn't cause crash dump to fail.
    Signed-off-by: default avatarGreg Pearson <greg.pearson@hp.com>
    Acked-by: default avatarVivek Goyal <vgoyal@redhat.com>
    Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
    Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    38dfac84
vmcore.c 27.8 KB