linux-kernel - Re: [PATCH] x86/amd_nb: Use kmalloc_array() in amd_cache

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: <1473017022.5018.58.camel@perches.com>
Date:   Sun, 04 Sep 2016 12:23:42 -0700
From:   Joe Perches <joe@...ches.com>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>, x86@...nel.org,
        Borislav Petkov <bp@...e.de>, "H. Peter Anvin" <hpa@...or.com>,
        Ingo Molnar <mingo@...hat.com>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org,
        Julia Lawall <julia.lawall@...6.fr>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH] x86/amd_nb: Use kmalloc_array() in amd_cache_gart()

On Sun, 2016-09-04 at 21:08 +0200, SF Markus Elfring wrote:

> * A multiplication for the size determination of a memory allocation
>   indicated that an array data structure should be processed.
>   Thus use the corresponding function "kmalloc_array".
> 
>   This issue was detected by using the Coccinelle software.
> 
> * Replace the specification of a data type by a pointer dereference
>   to make the corresponding size determination a bit safer according to
>   the Linux coding style convention.
[]
> diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
[]
> @@ -226,7 +226,9 @@ static void amd_cache_gart(void)
>  	if (!amd_nb_has_feature(AMD_NB_GART))
>  		return;
>  
> -	flush_words = kmalloc(amd_nb_num() * sizeof(u32), GFP_KERNEL);
> +	flush_words = kmalloc_array(amd_nb_num(),
> +				    sizeof(*flush_words),
> +				    GFP_KERNEL);

Markus, this sort of change really isn't very useful.

amd_nb_num is a u16 and is really just a count of
northbridges in the system.

It'll never be a particular high number that could
possibly overflow a size_t of num * sizeof(u32).

Detecting an inconsistency is different than an issue
that has any real significance.

Please stop blindly converting these from one form to
another.  Please inspect these potential changes
first and find instances where this conversion could
actually matter before sending auto-generated patches.