The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Laura Abbott <labbott@redhat.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	kernel-hardening@lists.openwall.com,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH] drm/i2c: tda998x: Remove VLA usage
Date: Tue, 10 Apr 2018 14:52:35 -0700	[thread overview]
Message-ID: <855433a0-72f5-df29-3a17-5c2016e988e1@redhat.com> (raw)
In-Reply-To: <20180409222141.GR16141@n2100.armlinux.org.uk>

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

  reply	other threads:[~2018-04-10 21:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-09 21:07 [PATCH] drm/i2c: tda998x: Remove VLA usage Laura Abbott
2018-04-09 22:21 ` Russell King - ARM Linux
2018-04-10 21:52   ` Laura Abbott [this message]
2018-04-10 22:06     ` Russell King - ARM Linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=855433a0-72f5-df29-3a17-5c2016e988e1@redhat.com \
    --to=labbott@redhat.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox