linux-kernel - Re: [PATCH] fs/proc/vmcore: a few cleanups for vmcore_add_device

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: <d60db71a-0b4f-4e7d-8c06-7493934aa507@suswa.mountain>
Date: Mon, 23 Jun 2025 18:22:25 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Baoquan He <bhe@...hat.com>
Cc: Su Hui <suhui@...china.com>, akpm@...ux-foundation.org,
	vgoyal@...hat.com, dyoung@...hat.com, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] fs/proc/vmcore: a few cleanups for vmcore_add_device_dump

On Mon, Jun 23, 2025 at 10:36:45PM +0800, Baoquan He wrote:
> On 06/23/25 at 06:47pm, Su Hui wrote:
> > There are three cleanups for vmcore_add_device_dump(). Adjust data_size's
> > type from 'size_t' to 'unsigned int' for the consistency of data->size.
> 
> It's unclear to me why size_t is not suggested here. Isn't it assigned
> a 'sizeof() + data->size' in which size_t should be used?

Yeah...  That's a good point.  People should generally default to size_t
for sizes.  It really does prevent a lot of integer overflow bugs.  In
this case data->size is not controlled by the user, but if it were
then that would be an integer overflow on 32bit systems and not on
64bit systems, until we start declaring sizes as unsigned int and
then all the 32bit bugs start affecting everyone.

regards,
dan carpenter