linux-kernel - Re: (EXT) Re: [PATCH 4/8] media: imx: Fail conversion if pixel format not supported

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, 8 Feb 2022 03:14:57 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Alexander Stein <alexander.stein@...tq-group.com>
Cc:     Dorota Czaplejewicz <dorota.czaplejewicz@...i.sm>,
        Steve Longerbeam <slongerbeam@...il.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Rui Miguel Silva <rmfrfs@...il.com>,
        linux-media@...r.kernel.org, linux-staging@...ts.linux.dev,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: (EXT) Re: [PATCH 4/8] media: imx: Fail conversion if pixel
 format not supported

Hello,

On Mon, Feb 07, 2022 at 10:52:00AM +0100, Alexander Stein wrote:
> Am Samstag, 5. Februar 2022, 08:51:51 CET schrieb Dorota Czaplejewicz:
> > On Sat, 5 Feb 2022 06:07:37 +0200 Laurent Pinchart wrote:
> > > On Fri, Feb 04, 2022 at 01:15:10PM +0100, Alexander Stein wrote:
> > > > From: Dorota Czaplejewicz <dorota.czaplejewicz@...i.sm>
> > > > 
> > > > imx_media_find_mbus_format has NULL as a valid return value,
> > > > therefore the caller should take it into account.
> > > > 
> > > > Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@...i.sm>
> > > > Signed-off-by: Alexander Stein <alexander.stein@...tq-group.com>
> > > > ---
> > > > 
> > > >  drivers/staging/media/imx/imx-media-utils.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/drivers/staging/media/imx/imx-media-utils.c
> > > > b/drivers/staging/media/imx/imx-media-utils.c index
> > > > 32aaa2e81bea..e0a256a08c3b 100644
> > > > --- a/drivers/staging/media/imx/imx-media-utils.c
> > > > +++ b/drivers/staging/media/imx/imx-media-utils.c
> > > > @@ -544,6 +544,9 @@ static int imx56_media_mbus_fmt_to_pix_fmt(struct
> > > > v4l2_pix_format *pix,> > 
> > > >  		cc = imx_media_find_mbus_format(code, PIXFMT_SEL_YUV);
> > > 
> > > The code passed to the function comes from the previous line:
> > > 	imx_media_enum_mbus_formats(&code, 0, PIXFMT_SEL_YUV);
> > > 
> > > As far as I can tell, this is guaranteed to return a code that will
> > > result in imx_media_find_mbus_format() returning a non-NULL pointer.
> > 
> > While I am not well-versed in the implicit code style of the kernel, I
> > decided to leave it in because it makes the code more locally legible. With
> > a check here, even a non-functional one, there's no need to understand the
> > internals of `imx_media_find_mbus_format` that are only implicit. That
> > makes the code less surprising when interested only in the outer function.
> > 
> > The other advantage of a check is becoming robust against future changes to
> > `imx_media_find_mbus_format` itself.
> > 
> > I don't have a strong preference about keeping or leaving this patch, but if
> > this check was there in the first place, I wouldn't have spent time trying
> > to figure out whether there's a bug here.
> 
> Laurent, thanks for your feedback.
> I'm on Dorota's side here. While you are right that the code from 
>   imx_media_enum_mbus_formats(&code, 0, PIXFMT_SEL_YUV);
> is guaranteed to return something. I don't lnek this implicit assumption over 
> 2 function calls. Better be safe than sorry. For that reason code should be 
> initialized as well. Will create a patch for that.

I'm fine with hardening the code even if the issue can't occur at the
moment.

-- 
Regards,

Laurent Pinchart