Linux Media Controller development
 help / color / mirror / Atom feed
From: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
To: David CARLIER <devnexen@gmail.com>
Cc: Jacopo Mondi <jacopo.mondi@ideasonboard.com>,
	 Mauro Carvalho Chehab <mchehab@kernel.org>,
	Michael Riesch <michael.riesch@collabora.com>,
	 Daniel Scally <dan.scally@ideasonboard.com>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	 Hans Verkuil <hverkuil+cisco@kernel.org>,
	stable@vger.kernel.org,
	 Sakari Ailus <sakari.ailus@linux.intel.com>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: v4l2-isp: reject zero-sized parameter blocks
Date: Tue, 18 Aug 2026 08:31:08 +0200	[thread overview]
Message-ID: <aoP7A6oYPkjmh3gv@zed> (raw)
In-Reply-To: <CA+XhMqxY3u5YR06j8jX2+wCwX95vQrb5EVH39GvuJXrwA48XWw@mail.gmail.com>

Hi David,

On Mon, Aug 17, 2026 at 05:19:18PM +0100, David CARLIER wrote:
> On Mon, Aug 17, 2026 at 05:56:30PM +0200, Jacopo Mondi wrote:
> > Should we instead deman that all entries provided by the driver are
> > populated by failing validation if info->size == 0 ?
>
> Good idea, and I'd rather keep both in v2 if you don't mind - they
> guard different things.
>
> info->size == 0 is about the driver table, and it lets us answer
> "this driver doesn't handle that type" rather than carrying on with
> an empty entry and a NULL block_validate.

Do you think we should fail validation because the info table has
holes or we should simply skip entries with info->size == 0 ?

I'm leaning towards the latter fwiw

>
> block->size < sizeof(*block) is about the buffer coming from
> userspace: a block's size includes its header, so anything smaller is
> malformed no matter what the table says, and it keeps the loop moving
> without depending on the table at all.
>
> Both are a couple of lines, so dropping either one is no trouble if
> you prefer.
>
> > Right.. you might have seen ?
> > https://patchwork.linuxtv.org/project/linux-media/list/?series=29170
>
> I hadn't, thanks. That takes care of the rppx1 side, so there's
> nothing left for me to send there and I'll stick to the core change.
>
> I'll reword the commit message so it doesn't lean on rppx1, and keep
> Cc: stable unless you disagree.
>

Yes thanks, as v4l2-isp went in in v6.19 this is worth a Fixes tag I
think..


> Cheers.

      reply	other threads:[~2026-08-18  6:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-15 19:38 [PATCH] media: v4l2-isp: reject zero-sized parameter blocks David Carlier
2026-08-17  9:59 ` Jacopo Mondi
2026-08-17 13:40   ` David CARLIER
2026-08-17 15:56     ` Jacopo Mondi
2026-08-17 16:19       ` David CARLIER
2026-08-18  6:31         ` Jacopo Mondi [this message]

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=aoP7A6oYPkjmh3gv@zed \
    --to=jacopo.mondi@ideasonboard.com \
    --cc=dan.scally@ideasonboard.com \
    --cc=devnexen@gmail.com \
    --cc=hverkuil+cisco@kernel.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=michael.riesch@collabora.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=stable@vger.kernel.org \
    /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