linux-kernel - Re: [PATCH] x86/microcode/amd: fix uninitalized structure cp

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: <fcbb34b0-203e-0c7c-66cc-a3ae6fa3680c@canonical.com>
Date:   Tue, 14 Jan 2020 14:08:50 +0000
From:   Colin Ian King <colin.king@...onical.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/microcode/amd: fix uninitalized structure cp

On 14/01/2020 12:10, Borislav Petkov wrote:
> On Tue, Jan 14, 2020 at 12:03:36PM +0000, Colin Ian King wrote:
>> On 14/01/2020 12:01, Borislav Petkov wrote:
>>> On Tue, Jan 14, 2020 at 11:51:43AM +0000, Colin Ian King wrote:
>>>> Starting at load_ucode_amd_bsp(), this initializes a local cp to zero,
>>>> then passes &cp when it calls __load_ucode_amd() as parameter *ret.  In
>>>> __load_ucode_amd a new local cp is created on the stack and *only* is
>>>> assigned here:
>>>>
>>>>        if (!get_builtin_microcode(&cp, x86_family(cpuid_1_eax)))
>>>>                 cp = find_microcode_in_initrd(path, use_pa);
>>>
>>> Is there any case where cp doesn't get assigned here? Either by
>>> get_builtin_microcode() or by find_microcode_in_initrd()?

If I understand the question, it seems that get_builtin_microcode()
tries to load in the appropriate amd microcode binary from the cpio data
and this can potentially fail if the microcode is not provided for the
specific processor family, so I believe this is a legitimate fix.

Colin


> ^^^^^^^^^^^^^
> 
> You missed this question.
> 
>> OK, I will try to extract every special Tag from Coverity and get this
>> documented when I get some spare cycles.
> 
> tglx just explained to me the whole situation about coverity.
> 
> I'm not asking about extracting special tags but rather about a
> couple of sentences somewhere in Documentation/ explaining what
> Addresses-Coverity* means for the unenlightened among us and how one can
> find further invormation.
> 
> Reportedly, there's even a web page with the tags somewhere...
> 
> Thx.
>