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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170105101727.jutfvokxxdi4hxl6@pd.tnic>
Date:   Thu, 5 Jan 2017 11:17:27 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Junichi Nomura <j-nomura@...jp.nec.com>
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 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.