Re: [PATCH v2] drm/nouveau/secboot: remove VLA usage

From: Kees Cook
Date: Wed May 23 2018 - 19:54:32 EST


On Wed, May 23, 2018 at 5:36 PM, Ben Skeggs <bskeggs@xxxxxxxxxx> wrote:
> On Thu, May 24, 2018 at 8:48 AM, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>> On Thu, Apr 26, 2018 at 4:25 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>>> On Thu, Mar 15, 2018 at 7:05 PM, Ben Skeggs <skeggsb@xxxxxxxxx> wrote:
>>>> On 14 March 2018 at 21:08, Thierry Reding <thierry.reding@xxxxxxxxx> wrote:
>>>>> On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote:
>>>>>> In preparation to enabling -Wvla, remove VLA. In this particular
>>>>>> case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local
>>>>>> variable cmdline_size. Also, remove cmdline_size as it is not
>>>>>> actually useful anymore.
>>>>>>
>>>>>> The use of stack Variable Length Arrays needs to be avoided, as they
>>>>>> can be a vector for stack exhaustion, which can be both a runtime bug
>>>>>> or a security flaw. Also, in general, as code evolves it is easy to
>>>>>> lose track of how big a VLA can get. Thus, we can end up having runtime
>>>>>> failures that are hard to debug.
>>>>>>
>>>>>> Also, fixed as part of the directive to remove all VLAs from
>>>>>> the kernel: https://lkml.org/lkml/2018/3/7/621
>>>>>>
>>>>>> Signed-off-by: Gustavo A. R. Silva <gustavo@xxxxxxxxxxxxxx>
>>>>>> ---
>>>>>> Changes in v2:
>>>>>> - Use sizeof(buf) instead of NVKM_MSGQUEUE_CMDLINE_SIZE. This change
>>>>>> is based on the feedback provided by David Laight. Thanks David.
>>>>>>
>>>>>> drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_msgqueue.c | 7 +++----
>>>>>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>>>>
>>>>> Reviewed-by: Thierry Reding <treding@xxxxxxxxxx>
>>>> Thanks everyone. I've taken the patch in my tree.
>>>
>>> Hi!
>>>
>>> Just checking in on this -- I don't see this patch in linux-next. Is
>>> this queued somewhere else?
>>
>> Hi, it's been another month; I still don't see this in linux-next.
>> Daniel, can this go via drm-misc?
> It's already queued in drm-next.

Ah-ha, great, thanks! Looks like I just got unlucky with linux-next
pausing on the 17th and this getting committed on the 18th. :) But,
yes, I see it now:
https://cgit.freedesktop.org/drm/drm/commit/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_msgqueue.c?id=7bf5b70befd7817b9e42acbd2291b2042ea1bf81

-Kees

--
Kees Cook
Pixel Security