linux-hardening - Re: [PATCH] crypto: using size

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: <fe8468d5-7bb3-4acf-960f-fa23a0000faa@nfschina.com>
Date: Mon, 21 Apr 2025 16:50:30 +0800
From: Su Hui <suhui@...china.com>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>, davem@...emloft.net,
 herbert@...dor.apana.org.au
Cc: linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
 kernel-janitors@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] crypto: using size_add() for kmalloc()

On 2025/4/21 16:46, Su Hui wrote:
> On 2025/4/21 16:32, Christophe JAILLET wrote:
>> Le 21/04/2025 à 09:43, Su Hui a écrit :
>>> On 2025/4/21 15:10, Christophe JAILLET wrote:
>>>> Le 21/04/2025 à 07:51, Su Hui a écrit :
>>>>> It's safer to use size_add() to replace open-coded aithmetic in 
>>>>> allocator
>>>>> arguments, because size_add() can prevent possible overflow problem.
>>>>>
>>>>> Signed-off-by: Su Hui <suhui@...china.com>
>>>>> ---
>>>>>   include/crypto/aead.h     | 3 ++-
>>>>>   include/crypto/akcipher.h | 4 +++-
>>>>>   include/crypto/kpp.h      | 3 ++-
>>>>>   3 files changed, 7 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/include/crypto/aead.h b/include/crypto/aead.h
>>>>> index 0e8a41638678..cf212d28fe18 100644
>>>>> --- a/include/crypto/aead.h
>>>>> +++ b/include/crypto/aead.h
>>>>> @@ -10,6 +10,7 @@
>>>>>     #include <linux/atomic.h>
>>>>>   #include <linux/container_of.h>
>>>>> +#include <linux/overflow.h>
>>>>
>>>> You could move this 1 line below, to keep alphabetical order.
>>>> And why do you say that it is redundant in your follow-up mail?
>>> Thanks for your suggestion, I didn't notice this alphabetical order 
>>> at first :( .
>>> Because I found that  <linux/crypto.h> includes <linux/slab.h>, and
>>> <linux/slab.h> includes <linux/overflow.h>, so this overflow.h is 
>>> redundant.
>>
>> It is usually considered best practice to include what is used, and 
>> not relying on indirect includes.
>>
>> Should these others includes change one day, then some apparently 
>> unrelated files will fails to built.
>>
> I already send a v2 patch, too fast for this v2 sending :(.
> v2: 
> https://lore.kernel.org/all/20250421083116.1161805-1-suhui@nfschina.com/
>
> I agreed with 'include what is used'.  So I guess v1 is enough and v2 
> maybe a wrong patchset.
> Sorry for the noise.

Oh, I forget to keep alphabetical order, so v3 is needed if there is no 
other suggestions.