linux-kernel - Re: [PATCH AUTOSEL 5.3 169/203] x86/platform/uv: Fix kmalloc() NULL check routine

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] [day] [month] [year] [list]

Message-ID: <c3ecfbb0-b1d2-9af9-97e9-408a45b696d4@hpe.com>
Date:   Wed, 2 Oct 2019 07:35:59 -0700
From:   Mike Travis <mike.travis@....com>
To:     David Laight <David.Laight@...LAB.COM>,
        'Sasha Levin' <sashal@...nel.org>,
        Greg KH <gregkh@...uxfoundation.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Austin Kim <austindh.kim@...il.com>,
        Dimitri Sivanich <dimitri.sivanich@....com>,
        Hedi Berriche <hedi.berriche@....com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Russ Anderson <russ.anderson@....com>,
        Steve Wahl <steve.wahl@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "allison@...utok.net" <allison@...utok.net>,
        "andy@...radead.org" <andy@...radead.org>,
        "armijn@...ldur.nl" <armijn@...ldur.nl>,
        "bp@...en8.de" <bp@...en8.de>,
        "dvhart@...radead.org" <dvhart@...radead.org>,
        "hpa@...or.com" <hpa@...or.com>, "kjlu@....edu" <kjlu@....edu>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH AUTOSEL 5.3 169/203] x86/platform/uv: Fix kmalloc() NULL
 check routine



On 10/2/2019 1:34 AM, David Laight wrote:
> From: Sasha Levin
>> Sent: 01 October 2019 17:06
>> Subject: Re: [PATCH AUTOSEL 5.3 169/203] x86/platform/uv: Fix kmalloc() NULL check routine
>>
>> On Sun, Sep 22, 2019 at 10:25:44PM +0200, Greg KH wrote:
>>> On Sun, Sep 22, 2019 at 02:43:15PM -0400, Sasha Levin wrote:
>>>> From: Austin Kim <austindh.kim@...il.com>
>>>>
>>>> [ Upstream commit 864b23f0169d5bff677e8443a7a90dfd6b090afc ]
>>>>
>>>> The result of kmalloc() should have been checked ahead of below statement:
>>>>
>>>> 	pqp = (struct bau_pq_entry *)vp;
>>>>
>>>> Move BUG_ON(!vp) before above statement.
>>>>
>>>> Signed-off-by: Austin Kim <austindh.kim@...il.com>
> ...
>>>> ---
>>>>   arch/x86/platform/uv/tlb_uv.c | 4 ++--
>>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
>>>> index 20c389a91b803..5f0a96bf27a1f 100644
>>>> --- a/arch/x86/platform/uv/tlb_uv.c
>>>> +++ b/arch/x86/platform/uv/tlb_uv.c
>>>> @@ -1804,9 +1804,9 @@ static void pq_init(int node, int pnode)
>>>>
>>>>   	plsize = (DEST_Q_SIZE + 1) * sizeof(struct bau_pq_entry);
>>>>   	vp = kmalloc_node(plsize, GFP_KERNEL, node);
>>>> -	pqp = (struct bau_pq_entry *)vp;
>>>> -	BUG_ON(!pqp);
>>>> +	BUG_ON(!vp);
>>>>
>>>> +	pqp = (struct bau_pq_entry *)vp;
>>>>   	cp = (char *)pqp + 31;
>>>>   	pqp = (struct bau_pq_entry *)(((unsigned long)cp >> 5) << 5);
>>>>
>>>
>>> How did this even get merged in the first place?  I thought a number of
>>> us complained about it.
>>>
>>> This isn't any change in code, and the original is just fine, the author
>>> didn't realize how C works :(
> 
> Mind you, the code itself if pretty horrid.
> Looks like it is aligning to 32 bytes, easier done by:
> 	pqp = (void *)((unsigned long)vp + 31 & ~31);
> (and there's a roundup macro to obfuscate it somewhere.)
> But I'd also expect to see a matching '+ 31' in the size passed to kmalloc().
> Not to mention a comment!
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
> 

Thanks, I will put all of these comments in my notes.  This whole 
function is slated to move to a specialized UV APIC driver since it uses 
a unique scaling feature available in the UV hardware.  (The original 
author has long retired.)

-Mike