diff mbox series

media: sq905.c: fix uninitialized variable

Message ID 20210325212202.142945-1-alaaemadhossney.ae@gmail.com
State New
Headers show
Series media: sq905.c: fix uninitialized variable | expand

Commit Message

Alaa Emad March 25, 2021, 9:22 p.m. UTC
Reported-by: syzbot+a4e309017a5f3a24c7b3@syzkaller.appspotmail.com
Signed-off-by: Alaa Emad <alaaemadhossney.ae@gmail.com>
---
 drivers/media/usb/gspca/sq905.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Greg Kroah-Hartman March 26, 2021, 7:11 a.m. UTC | #1
On Thu, Mar 25, 2021 at 11:22:02PM +0200, Alaa Emad wrote:
> Reported-by: syzbot+a4e309017a5f3a24c7b3@syzkaller.appspotmail.com

> Signed-off-by: Alaa Emad <alaaemadhossney.ae@gmail.com>

> ---


I know I do not take patches with no changelog text, but other
maintainers might be more leniant :(

thanks,

greg k-h
Dmitry Vyukov March 26, 2021, 7:14 a.m. UTC | #2
On Fri, Mar 26, 2021 at 8:11 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>

> On Thu, Mar 25, 2021 at 11:22:02PM +0200, Alaa Emad wrote:

> > Reported-by: syzbot+a4e309017a5f3a24c7b3@syzkaller.appspotmail.com

> > Signed-off-by: Alaa Emad <alaaemadhossney.ae@gmail.com>

> > ---

>

> I know I do not take patches with no changelog text, but other

> maintainers might be more leniant :(


I wonder if it's the right fix or not.
Initializing variables will, of course, silence the warning, but it's
not necessarily the right fix. I suspect there is something wrong in
how ret/act_len are user/checked.
Pavel Skripkin March 26, 2021, 7:24 a.m. UTC | #3
Hi!

On Fri, 2021-03-26 at 08:14 +0100, 'Dmitry Vyukov' via syzkaller wrote:
> On Fri, Mar 26, 2021 at 8:11 AM Greg KH <gregkh@linuxfoundation.org>

> wrote:

> > 

> > On Thu, Mar 25, 2021 at 11:22:02PM +0200, Alaa Emad wrote:

> > > Reported-by: syzbot+a4e309017a5f3a24c7b3@syzkaller.appspotmail.com

> > > Signed-off-by: Alaa Emad <alaaemadhossney.ae@gmail.com>

> > > ---

> > 

> > I know I do not take patches with no changelog text, but other

> > maintainers might be more leniant :(

> 

> I wonder if it's the right fix or not.

> Initializing variables will, of course, silence the warning, but it's

> not necessarily the right fix. I suspect there is something wrong in

> how ret/act_len are user/checked.

> 


There is a problem in usb_bulk_msg() call. It could return before
act_len initialization, so i think, act_len should be intialized with
smth wrong like 0 or -1. BTW, I already send patch for that, but it was
marked as obsoleted.

--
With regards,

Pavel Skripkin
Dmitry Vyukov March 26, 2021, 7:40 a.m. UTC | #4
On Fri, Mar 26, 2021 at 8:24 AM Pavel Skripkin <paskripkin@gmail.com> wrote:
>

> Hi!

>

> On Fri, 2021-03-26 at 08:14 +0100, 'Dmitry Vyukov' via syzkaller wrote:

> > On Fri, Mar 26, 2021 at 8:11 AM Greg KH <gregkh@linuxfoundation.org>

> > wrote:

> > >

> > > On Thu, Mar 25, 2021 at 11:22:02PM +0200, Alaa Emad wrote:

> > > > Reported-by: syzbot+a4e309017a5f3a24c7b3@syzkaller.appspotmail.com

> > > > Signed-off-by: Alaa Emad <alaaemadhossney.ae@gmail.com>

> > > > ---

> > >

> > > I know I do not take patches with no changelog text, but other

> > > maintainers might be more leniant :(

> >

> > I wonder if it's the right fix or not.

> > Initializing variables will, of course, silence the warning, but it's

> > not necessarily the right fix. I suspect there is something wrong in

> > how ret/act_len are user/checked.

> >

>

> There is a problem in usb_bulk_msg() call. It could return before

> act_len initialization, so i think, act_len should be intialized with

> smth wrong like 0 or -1. BTW, I already send patch for that, but it was

> marked as obsoleted.


If usb_bulk_msg returns before act_len initialization, it should
signify that fact with an error code in return value or something,
right? It does not initialize act_len only in case of errors, right?
If so, sq905_read_data must check ret and don't use act_for any
checks. But it does, and that's I think the bug. Or maybe usb_bulk_msg
does not properly signify that it failed (and did not initialize
act_len). Either way silencing the warning with pre-initializing
act_len looks very fishy.
For example, consider, in some contexts it's OK to transmit 0-length
packets, I don't know if it's the case for usb_bulk_msg or not, but it
does not affect the idea. Now, if we pre-initialize act_len to 0, we
can falsely think that such 0-length transfer has succeeded (act_len
== size), while it actually failed (I assume so since usb_bulk_msg
left act_len unitialized).
Pavel Skripkin March 26, 2021, 7:53 a.m. UTC | #5
Hi!

On Fri, 2021-03-26 at 08:40 +0100, Dmitry Vyukov wrote:
> On Fri, Mar 26, 2021 at 8:24 AM Pavel Skripkin <paskripkin@gmail.com>

> wrote:

> > 

> > Hi!

> > 

> > On Fri, 2021-03-26 at 08:14 +0100, 'Dmitry Vyukov' via syzkaller

> > wrote:

> > > On Fri, Mar 26, 2021 at 8:11 AM Greg KH

> > > <gregkh@linuxfoundation.org>

> > > wrote:

> > > > 

> > > > On Thu, Mar 25, 2021 at 11:22:02PM +0200, Alaa Emad wrote:

> > > > > Reported-by:

> > > > > syzbot+a4e309017a5f3a24c7b3@syzkaller.appspotmail.com

> > > > > Signed-off-by: Alaa Emad <alaaemadhossney.ae@gmail.com>

> > > > > ---

> > > > 

> > > > I know I do not take patches with no changelog text, but other

> > > > maintainers might be more leniant :(

> > > 

> > > I wonder if it's the right fix or not.

> > > Initializing variables will, of course, silence the warning, but

> > > it's

> > > not necessarily the right fix. I suspect there is something wrong

> > > in

> > > how ret/act_len are user/checked.

> > > 

> > 

> > There is a problem in usb_bulk_msg() call. It could return before

> > act_len initialization, so i think, act_len should be intialized with

> > smth wrong like 0 or -1. BTW, I already send patch for that, but it

> > was

> > marked as obsoleted.

> 

> If usb_bulk_msg returns before act_len initialization, it should

> signify that fact with an error code in return value or something,

> right? It does not initialize act_len only in case of errors, right?

> If so, sq905_read_data must check ret and don't use act_for any

> checks. But it does, and that's I think the bug. Or maybe usb_bulk_msg

> does not properly signify that it failed (and did not initialize

> act_len). Either way silencing the warning with pre-initializing

> act_len looks very fishy.

> For example, consider, in some contexts it's OK to transmit 0-length

> packets, I don't know if it's the case for usb_bulk_msg or not, but it

> does not affect the idea. Now, if we pre-initialize act_len to 0, we

> can falsely think that such 0-length transfer has succeeded (act_len

> == size), while it actually failed (I assume so since usb_bulk_msg

> left act_len unitialized).


You are absolutely rigth, and sq905_read_data doesn't use act_len for
checks in case of usb_bulk_msg fail. But it uses it for error printing:

	if (ret < 0 || act_len != size) {
		pr_err("bulk read fail (%d) len %d/%d\n", ret,
act_len, size);
		return -EIO;
	}

So, value like -1 can be a flag for smth went wrong internally. Or
maybe remove this error log and replace it with other, which will rely
on error code, idk how it will be better
--
With regards,
Pavel Skripkin
Dmitry Vyukov March 26, 2021, 8:06 a.m. UTC | #6
On Fri, Mar 26, 2021 at 8:53 AM Pavel Skripkin <paskripkin@gmail.com> wrote:
>

> Hi!

>

> On Fri, 2021-03-26 at 08:40 +0100, Dmitry Vyukov wrote:

> > On Fri, Mar 26, 2021 at 8:24 AM Pavel Skripkin <paskripkin@gmail.com>

> > wrote:

> > >

> > > Hi!

> > >

> > > On Fri, 2021-03-26 at 08:14 +0100, 'Dmitry Vyukov' via syzkaller

> > > wrote:

> > > > On Fri, Mar 26, 2021 at 8:11 AM Greg KH

> > > > <gregkh@linuxfoundation.org>

> > > > wrote:

> > > > >

> > > > > On Thu, Mar 25, 2021 at 11:22:02PM +0200, Alaa Emad wrote:

> > > > > > Reported-by:

> > > > > > syzbot+a4e309017a5f3a24c7b3@syzkaller.appspotmail.com

> > > > > > Signed-off-by: Alaa Emad <alaaemadhossney.ae@gmail.com>

> > > > > > ---

> > > > >

> > > > > I know I do not take patches with no changelog text, but other

> > > > > maintainers might be more leniant :(

> > > >

> > > > I wonder if it's the right fix or not.

> > > > Initializing variables will, of course, silence the warning, but

> > > > it's

> > > > not necessarily the right fix. I suspect there is something wrong

> > > > in

> > > > how ret/act_len are user/checked.

> > > >

> > >

> > > There is a problem in usb_bulk_msg() call. It could return before

> > > act_len initialization, so i think, act_len should be intialized with

> > > smth wrong like 0 or -1. BTW, I already send patch for that, but it

> > > was

> > > marked as obsoleted.

> >

> > If usb_bulk_msg returns before act_len initialization, it should

> > signify that fact with an error code in return value or something,

> > right? It does not initialize act_len only in case of errors, right?

> > If so, sq905_read_data must check ret and don't use act_for any

> > checks. But it does, and that's I think the bug. Or maybe usb_bulk_msg

> > does not properly signify that it failed (and did not initialize

> > act_len). Either way silencing the warning with pre-initializing

> > act_len looks very fishy.

> > For example, consider, in some contexts it's OK to transmit 0-length

> > packets, I don't know if it's the case for usb_bulk_msg or not, but it

> > does not affect the idea. Now, if we pre-initialize act_len to 0, we

> > can falsely think that such 0-length transfer has succeeded (act_len

> > == size), while it actually failed (I assume so since usb_bulk_msg

> > left act_len unitialized).

>

> You are absolutely rigth, and sq905_read_data doesn't use act_len for

> checks in case of usb_bulk_msg fail. But it uses it for error printing:

>

>         if (ret < 0 || act_len != size) {

>                 pr_err("bulk read fail (%d) len %d/%d\n", ret,

> act_len, size);

>                 return -EIO;

>         }

>

> So, value like -1 can be a flag for smth went wrong internally. Or

> maybe remove this error log and replace it with other, which will rely

> on error code, idk how it will be better


Oh, you are right.
I was thinking it's the "ret < 0 || act_len != size" check where we
use uninit act_len, which would be much worse.
We could preinitialize act_len to, say, -1. But future readers may be
confused as to why we need to init it (as I was confused).
So another option may be to handle it during printing as:

pr_err("bulk read fail (%d) len %d/%d\n", ret, ret < 0 ? -1 : act_len, size);

It makes the intentions very explicit for a future reader.
diff mbox series

Patch

diff --git a/drivers/media/usb/gspca/sq905.c b/drivers/media/usb/gspca/sq905.c
index 97799cfb832e..54b733002f5c 100644
--- a/drivers/media/usb/gspca/sq905.c
+++ b/drivers/media/usb/gspca/sq905.c
@@ -157,8 +157,8 @@  static int sq905_ack_frame(struct gspca_dev *gspca_dev)
 static int
 sq905_read_data(struct gspca_dev *gspca_dev, u8 *data, int size, int need_lock)
 {
-	int ret;
-	int act_len;
+	int ret = 0;
+	int act_len = 0;
 
 	gspca_dev->usb_buf[0] = '\0';
 	if (need_lock)