[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e2b03b95-17ae-d734-d4a7-8f13e33147fc@ce.jp.nec.com>
Date: Thu, 5 Jan 2017 23:47:56 +0000
From: Junichi Nomura <j-nomura@...jp.nec.com>
To: Borislav Petkov <bp@...en8.de>
CC: "x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"hpa@...or.com" <hpa@...or.com>
Subject: Re: [PATCH] x86/microcode/intel: Use correct buffer size for saving
microcode data
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.
Powered by blists - more mailing lists