linux-kernel - Re: [syzbot] WARNING in usb_tx_block/usb_submit

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>] [day] [month] [year] [list]

Message-ID: <2878263.e9J7NaK4W3@suse>
Date:   Thu, 16 Feb 2023 10:21:33 +0100
From:   "Fabio M. De Francesco" <fmdefrancesco@...il.com>
To:     syzkaller-bugs@...glegroups.com
Cc:     syzbot <syzbot+355c68b459d1d96c4d06@...kaller.appspotmail.com>,
        syzkaller-bugs@...glegroups.com, linux-kernel@...r.kernel.org,
        Hillf Danton <hdanton@...a.com>
Subject: Re: [syzbot] WARNING in usb_tx_block/usb_submit_urb

On giovedì 16 febbraio 2023 09:18:34 CET Hillf Danton wrote:
> Fabio!
> 
> On Thu, 16 Feb 2023 07:54:08 +0100 Fabio M. De Francesco
> <fmdefrancesco@...il.com>
> > >  	do {
> > >  	
> > >  		int j =3D 0;
> > >  		i++;
> > > 
> > > -		if_usb_issue_boot_command(cardp, BOOT_CMD_FW_BY_USB);
> > 
> > Don't we need to call if_usb_issue_boot_command() in a loop in order to
> > retry
> > the command?
> 
> Nope certainly because of no sense made by sending it again, given no
> response this round.
> 

Your argument looks reasonable but...

For what regards subsystems/drivers whose I'm not expert I always assume that 
the authors know what they do despite bugs. I mean that looks more probable 
that they have reasons to issue several calls to if_usb_issue_boot_command() / 
usb_submit_urb in a loop. May be that those usb_submit_urb get lost in some 
particular conditions, since they decide to try if_usb_issue_boot_command() in 
a loop (but forget to kill the URB before next iteration).

I have no reasons to think you are wrong. However I don't understand the 
reason that made you leave the loops untouched (except the line with the call 
to if_usb_issue_boot_command().

I suppose that, if you confirm that we have no reasons to reiterate that call, 
you should also leave only one loop waiting for response.

Am I missing something?

Thanks,

Fabio