[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <03cc262da2a3db817aa5663fbce6c914708b74f8.camel@perches.com>
Date: Sat, 18 May 2024 18:19:18 -0700
From: Joe Perches <joe@...ches.com>
To: Guenter Roeck <linux@...ck-us.net>, 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 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)
> > return -ENOMEM;
> > } else {
> > args = (void *)stack;
> > }
> > ...
> > ret = nvif_object_ioctl(object, args, args_size, NULL);
> >
> > This will catch the u32 overflow to nvif_object_ioctl(), catch an
> > allocation underflow on 32-bits systems, and make the code more
> > readable. :)
> >
>
> Makes sense. I'll change that and send v2.
>
> Thanks,
> Guenter
>
>
Powered by blists - more mailing lists