• Borislav Petkov's avatar
    x86/microcode: Do not access the initrd after it has been freed · 24c25032
    Borislav Petkov authored
    When we look for microcode blobs, we first try builtin and if that
    doesn't succeed, we fallback to the initrd supplied to the kernel.
    
    However, at some point doing boot, that initrd gets jettisoned and we
    shouldn't access it anymore. But we do, as the below KASAN report shows.
    That's because find_microcode_in_initrd() doesn't check whether the
    initrd is still valid or not.
    
    So do that.
    
      ==================================================================
      BUG: KASAN: use-after-free in find_cpio_data
      Read of size 1 by task swapper/1/0
      page:ffffea0000db9d40 count:0 mapcount:0 mapping:          (null) index:0x1
      flags: 0x100000000000000()
      raw: 0100000000000000 0000000000000000 0000000000000001 00000000ffffffff
      raw: dead000000000100 dead000000000200 0000000000000000 0000000000000000
      page dumped because: kasan: bad access detected
      CPU: 1 PID: 0 Comm: swapper/1 Tainted: G        W       4.10.0-rc5-debug-00075-g2dbde22 #3
      Hardware name: Dell Inc. XPS 13 9360/0839Y6, BIOS 1.2.3 12/01/2016
      Call Trace:
       dump_stack
       ? _atomic_dec_and_lock
       ? __dump_page
       kasan_report_error
       ? pointer
       ? find_cpio_data
       __asan_report_load1_noabort
       ? find_cpio_data
       find_cpio_data
       ? vsprintf
       ? dump_stack
       ? get_ucode_user
       ? print_usage_bug
       find_microcode_in_initrd
       __load_ucode_intel
       ? collect_cpu_info_early
       ? debug_check_no_locks_freed
       load_ucode_intel_ap
       ? collect_cpu_info
       ? trace_hardirqs_on
       ? flat_send_IPI_mask_allbutself
       load_ucode_ap
       ? get_builtin_firmware
       ? flush_tlb_func
       ? do_raw_spin_trylock
       ? cpumask_weight
       cpu_init
       ? trace_hardirqs_off
       ? play_dead_common
       ? native_play_dead
       ? hlt_play_dead
       ? syscall_init
       ? arch_cpu_idle_dead
       ? do_idle
       start_secondary
       start_cpu
      Memory state around the buggy address:
       ffff880036e74f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ffff880036e74f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      >ffff880036e75000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                         ^
       ffff880036e75080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ffff880036e75100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      ==================================================================
    Reported-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
    Tested-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
    Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20170126165833.evjemhbqzaepirxo@pd.tnicSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    24c25032
amd.c 21.9 KB