On Fri, Mar 26, 2021 at 8:53 AM Pavel Skripkin <paskripkin@xxxxxxxxx> 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@xxxxxxxxx>
> > 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@xxxxxxxxxxxxxxxxxxx>
> > > > wrote:
> > > > >
> > > > > On Thu, Mar 25, 2021 at 11:22:02PM +0200, Alaa Emad wrote:
> > > > > > Reported-by:
> > > > > > syzbot+a4e309017a5f3a24c7b3@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > > > > Signed-off-by: Alaa Emad <alaaemadhossney.ae@xxxxxxxxx>
> > > > > > ---
> > > > >
> > > > > 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.
