From: Tarang Raval <tarang.raval@siliconsignals.io>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans Verkuil <hverkuil@xs4all.nl>,
Shravan Chippa <Shravan.Chippa@microchip.com>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] media: i2c: imx334: uninitialized variable in imx334_update_exp_gain()
Date: Wed, 30 Apr 2025 10:30:53 +0000 [thread overview]
Message-ID: <PN3P287MB1829F95ACF4B2D2C39AFDDBE8B832@PN3P287MB1829.INDP287.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <255a8604-5aa9-441a-a4d6-ebc592a00be9@stanley.mountain>
> On Wed, Apr 30, 2025 at 09:47:44AM +0000, Tarang Raval wrote:
> > Hi Dan,
> >
> > > The "ret" variable is not initialized on the success path. Set it to
> > > zero.
> > >
> > > Fixes: 7b19b0fc8ac8 ("media: i2c: imx334: Convert to CCI register access helpers")
> > > Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> > > ---
> > > drivers/media/i2c/imx334.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/media/i2c/imx334.c b/drivers/media/i2c/imx334.c
> > > index fc875072f859..846b9928d4e8 100644
> > > --- a/drivers/media/i2c/imx334.c
> > > +++ b/drivers/media/i2c/imx334.c
> > > @@ -536,7 +536,8 @@ static int imx334_update_controls(struct imx334 *imx334,
> > > static int imx334_update_exp_gain(struct imx334 *imx334, u32 exposure, u32 gain)
> > > {
> > > u32 lpfr, shutter;
> > > - int ret, ret_hold;
> > > + int ret_hold;
> > > + int ret = 0;
> >
> > I think this initialization may not really be necessary.
> >
> > If all of those cci_write are skipped, then yes, using ret uninitialized
> > would be a problem.
> >
> > However, I don’t see any case where they would be skipped in the
> > current implementation.
> >
> > So, is this initialization really needed?
> >
> > Best Regards,
> > Tarang
>
> This is a new bug that was introduced in linux-next...
>
> drivers/media/i2c/imx334.c
> 536 static int imx334_update_exp_gain(struct imx334 *imx334, u32 exposure, u32 gain)
> 537 {
> 538 u32 lpfr, shutter;
> 539 int ret, ret_hold;
> 540
> 541 lpfr = imx334->vblank + imx334->cur_mode->height;
> 542 shutter = lpfr - exposure;
> 543
> 544 dev_dbg(imx334->dev, "Set long exp %u analog gain %u sh0 %u lpfr %u\n",
> 545 exposure, gain, shutter, lpfr);
> 546
> 547 cci_write(imx334->cci, IMX334_REG_HOLD, 1, &ret);
>
> This first call will do an unitialized read of ret to check if it holds
> an error code.
>
> 548 cci_write(imx334->cci, IMX334_REG_VMAX, lpfr, &ret);
> 549 cci_write(imx334->cci, IMX334_REG_SHUTTER, shutter, &ret);
> 550 cci_write(imx334->cci, IMX334_REG_AGAIN, gain, &ret);
>
> cci_write() is designed to preserve the error codes from previous calls.
> It will only write error codes to "ret", it will not write success. If
> everything succeeds then "ret" is uninitialized.
Yes, correct
> 551
> 552 ret_hold = cci_write(imx334->cci, IMX334_REG_HOLD, 0, NULL);
> 553 if (ret_hold)
> 554 return ret_hold;
> 555
> 556 return ret;
> 557 }
>
> In production then everyone should run with INIT_STACK_ALL_ZERO. In that
> case everything works fine. However some older distributions do not use
> this option. Also in testing, I would encourage everyone to run with
> INIT_STACK_ALL_PATTERN.
I am not aware of the INIT_STACK_ALL_ZERO and INIT_STACK_ALL_PATTERN options.
I’ll read more about them
Best Regards,
Tarang
next prev parent reply other threads:[~2025-04-30 10:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-30 8:27 [PATCH 0/3] media: i2c: Fix some uninitialized return values Dan Carpenter
2025-04-30 8:27 ` [PATCH 1/3] media: i2c: imx334: uninitialized variable in imx334_update_exp_gain() Dan Carpenter
2025-04-30 9:47 ` Tarang Raval
2025-04-30 9:59 ` Dan Carpenter
2025-04-30 10:30 ` Tarang Raval [this message]
2025-04-30 8:27 ` [PATCH 2/3] media: i2c: ds90ub960: Fix uninitialized variable in ub960_serializer_temp_ramp() Dan Carpenter
2025-04-30 8:34 ` Jai Luthra
2025-04-30 8:27 ` [PATCH 3/3] media: i2c: ds90ub960: Fix uninitialized variable in ub960_rxport_bc_ser_config() Dan Carpenter
2025-04-30 8:35 ` Jai Luthra
2025-04-30 9:54 ` [PATCH 0/3] media: i2c: Fix some uninitialized return values Tarang Raval
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=PN3P287MB1829F95ACF4B2D2C39AFDDBE8B832@PN3P287MB1829.INDP287.PROD.OUTLOOK.COM \
--to=tarang.raval@siliconsignals.io \
--cc=Shravan.Chippa@microchip.com \
--cc=dan.carpenter@linaro.org \
--cc=hverkuil@xs4all.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
/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
all inboxes | Powered by JetHome®