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).
