linux-kernel - Re: [PATCH] drm/nouveau/nvif: Avoid build error due to potential integer overflows

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: <bf8af522-d4ee-47cd-82a8-635fc144b648@roeck-us.net>
Date: Sun, 19 May 2024 07:09:44 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Joe Perches <joe@...ches.com>, Kees Cook <keescook@...omium.org>,
 Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc: airlied@...il.com, dakr@...hat.com, daniel@...ll.ch,
 dri-devel@...ts.freedesktop.org, jani.nikula@...el.com, javierm@...hat.com,
 kherbst@...hat.com, linux-kernel@...r.kernel.org, lyude@...hat.com,
 mripard@...nel.org, nouveau@...ts.freedesktop.org, tzimmermann@...e.de,
 linux-hardening@...r.kernel.org
Subject: Re: [PATCH] drm/nouveau/nvif: Avoid build error due to potential
 integer overflows

On 5/18/24 18:19, Joe Perches wrote:
> On Sat, 2024-05-18 at 11:23 -0700, Guenter Roeck wrote:
>> On 5/18/24 10:32, Kees Cook wrote:
>>
> []
>>> I think the INT_MAX test is actually better in this case because
>>> nvif_object_ioctl()'s size argument is u32:
>>>
>>> ret = nvif_object_ioctl(object, args, sizeof(*args) + size, NULL);
>>>                                         ^^^^^^^^^^^^^^^^^^^^
>>>
>>> So that could wrap around, even though the allocation may not.
>>>
>>> Better yet, since "sizeof(*args) + size" is repeated 3 times in the
>>> function, I'd recommend:
>>>
>>> 	...
>>> 	u32 args_size;
>>>
>>> 	if (check_add_overflow(sizeof(*args), size, &args_size))
>>> 		return -ENOMEM;
>>> 	if (args_size > sizeof(stack)) {
>>> 		if (!(args = kmalloc(args_size, GFP_KERNEL)))
> 
> trivia:
> 
> More typical kernel style would use separate alloc and test
> 
> 		args = kmalloc(args_size, GFP_KERNEL);
> 		if (!args)
> 

Sure, I can do that as well. I'll wait a couple of days though before
sending v3 in case there are more change requests.

Guenter