From: Borislav Petkov
> Sent: 02 April 2019 11:02
>
> On Mon, Apr 01, 2019 at 07:53:46PM +0200, Jann Horn wrote:
> > Hm. request_microcode_fw() gets that buffer from
> > request_firmware_direct(), which does this:
> >
> > __module_get(THIS_MODULE);
> > ret = _request_firmware(firmw
On Mon, Apr 01, 2019 at 07:53:46PM +0200, Jann Horn wrote:
> Hm. request_microcode_fw() gets that buffer from
> request_firmware_direct(), which does this:
>
> __module_get(THIS_MODULE);
> ret = _request_firmware(firmware_p, name, device, NULL, 0,
>
From: Jann Horn
> Sent: 01 April 2019 18:54
...
> > This ->get_ucode_data() BIOS-code-like contraption has always bugged me
> > for being too ugly to live.
> >
> > How about we vmalloc() a properly sized buffer - both
> > generic_load_microcode() callers have the size - and then hand that
> > buffe
On Mon, Apr 1, 2019 at 7:30 PM Borislav Petkov wrote:
>
> On Fri, Mar 29, 2019 at 10:46:50PM +0100, Jann Horn wrote:
> > generic_load_microcode() deals with a pointer that can be either a kernel
> > pointer or a user pointer. Pass it around as a __user pointer so that it
> > can't be dereferenced
On Fri, Mar 29, 2019 at 10:46:50PM +0100, Jann Horn wrote:
> generic_load_microcode() deals with a pointer that can be either a kernel
> pointer or a user pointer. Pass it around as a __user pointer so that it
> can't be dereferenced accidentally while its address space is unknown.
> Use explicit c
5 matches
Mail list logo
