• J
    x86/microcode/intel: Use correct buffer size for saving microcode data · 2e86222c
    Junichi Nomura 提交于
    In generic_load_microcode(), curr_mc_size is the size of the last
    allocated buffer and since we have this performance "optimization"
    there to vmalloc a new buffer only when the current one is bigger,
    curr_mc_size ends up becoming the size of the biggest buffer we've seen
    so far.
    
    However, we end up saving the microcode patch which matches our CPU
    and its size is not curr_mc_size but the respective mc_size during the
    iteration while we're staring at it.
    
    So save that mc_size into a separate variable and use it to store the
    previously found microcode buffer.
    
    Without this fix, we could get oops like this:
    
      BUG: unable to handle kernel paging request at ffffc9000e30f000
      IP: __memcpy+0x12/0x20
      ...
      Call Trace:
      ? kmemdup+0x43/0x60
      __alloc_microcode_buf+0x44/0x70
      save_microcode_patch+0xd4/0x150
      generic_load_microcode+0x1b8/0x260
      request_microcode_user+0x15/0x20
      microcode_write+0x91/0x100
      __vfs_write+0x34/0x120
      vfs_write+0xc1/0x130
      SyS_write+0x56/0xc0
      do_syscall_64+0x6c/0x160
      entry_SYSCALL64_slow_path+0x25/0x25
    
    Fixes: 06b8534c ("x86/microcode: Rework microcode loading")
    Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com>
    Signed-off-by: NBorislav Petkov <bp@suse.de>
    Link: http://lkml.kernel.org/r/4f33cbfd-44f2-9bed-3b66-7446cd14256f@ce.jp.nec.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
    2e86222c
intel.c 21.0 KB