linux-kernel - Re: [PATCH] drm/i2c: tda998x: Remove VLA usage

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]

Date:   Tue, 10 Apr 2018 14:52:35 -0700
From:   Laura Abbott <labbott@...hat.com>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     David Airlie <airlied@...ux.ie>, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH] drm/i2c: tda998x: Remove VLA usage

On 04/09/2018 03:21 PM, Russell King - ARM Linux wrote:
> On Mon, Apr 09, 2018 at 02:07:03PM -0700, Laura Abbott wrote:
>> There's an ongoing effort to remove VLAs[1] from the kernel to eventually
>> turn on -Wvla. The vla in reg_write_range is based on the length of data
>> passed. The one use of a non-constant size for this range is bounded by
>> the size buffer passed to hdmi_infoframe_pack which is a fixed size.
>> Switch to this upper bound.
> 
> Does this _really_ make it safer?  What if the code is modified to write
> more than 32 bytes in the future?
> 
> Sorry, I don't think this is safer at all.
> 

Yeah I wasn't 100% sure about this one. Elsewhere, we've added bounds
checks against the new static size buffer so we could do that here
to ensure we don't overrun the stack if we do need to write more
than 32 bytes in the future. Another option is to switch to
a kmalloc buffer. Are either of those options acceptable to you or
do you have a better idea of how to get rid of the VLA?

Thanks,
Laura