Re: [PATCH] x86/microcode/intel: Use correct buffer size for saving microcode data

[Borislav Petkov]

On Thu, Jan 05, 2017 at 04:45:18AM +0000, Junichi Nomura wrote:
> On 01/05/17 10:02, Junichi Nomura wrote:
> > In generic_load_microcode(), curr_mc_size is the size of the last
> > allocated buffer and not always the size of the buffer pointed to by
> > "new_mc".
> ...
> > @@ -864,6 +864,7 @@ static enum ucode_state generic_load_microcode(int cpu, void *data, size_t size,
> >  			vfree(new_mc);
> >  			new_rev = mc_header.rev;
> >  			new_mc  = mc;
> > +			new_mc_size  = curr_mc_size;
> >  			mc = NULL;	/* trigger new vmalloc */
> 
> Oops, sorry. It should save "mc_size", not "curr_mc_size".
> 
> -------------------
> 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.

Thanks.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.