On 01/05/17 19:17, Borislav Petkov wrote: > On Thu, Jan 05, 2017 at 04:45:18AM +0000, Junichi Nomura wrote: >> In generic_load_microcode(), curr_mc_size is the size of the last >> allocated buffer and could be smaller than the actual size of the >> buffer pointed to by "new_mc". >> >> 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 > > I see you're using the old interface but how exactly do you trigger > this, i.e., can you give me the blob you're using and the exact steps > you're performing? I'd like to reproduce it here.
I'm seeing this on RHEL6-based userspace, where 'microcode_ctl -Qu' is run from udev automatically when microcode driver is loaded. The version of microcode_ctl is 1.17. The problem can be reproduced either with the one in RHEL6 ( microcode-20151106.dat) or with the latest blob from Intel, i.e. microcode-20161104.tgz. -- Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.
