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: <e7f3efae-3571-46c0-9035-2a763990527f@nfschina.com>
Date: Tue, 22 Apr 2025 09:30:55 +0800
From: Su Hui <suhui@...china.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: davem@...emloft.net, 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 20:05, Herbert Xu wrote:
> On Mon, Apr 21, 2025 at 01:51:06PM +0800, Su Hui wrote:
>> @@ -433,7 +434,7 @@ static inline struct aead_request *aead_request_alloc(struct crypto_aead *tfm,
>>   {
>>   	struct aead_request *req;
>>   
>> -	req = kmalloc(sizeof(*req) + crypto_aead_reqsize(tfm), gfp);
>> +	req = kmalloc(size_add(sizeof(*req), crypto_aead_reqsize(tfm)), gfp);
> This is just wrong.  You should fail the allocation altogether
> rather than proceeding with a length that is insufficient.
>
> However, reqsize shouldn't be anywhere near overflowing in the
> first place.  If you're truly worried about this, you should
> change the algorithm registration code to check whether reqsize
> is sane.
>
> And that needs to wait until the algorithms are fixed to not use
> dynamic reqsizes.
Got it, thanks for your explanation.
This patch (v1 and v2) is wrong.  Sorry for the noise again.

Su Hui