linux-kernel - Re: [syzbot] WARNING in rtl8152

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

Message-ID: <20210517134718.GC1083813@rowland.harvard.edu>
Date:   Mon, 17 May 2021 09:47:18 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Oliver Neukum <oneukum@...e.com>
Cc:     Hayes Wang <hayeswang@...ltek.com>,
        syzbot <syzbot+95afd23673f5dd295c57@...kaller.appspotmail.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
        nic_swsd <nic_swsd@...ltek.com>
Subject: Re: [syzbot] WARNING in rtl8152_probe

On Mon, May 17, 2021 at 12:00:19PM +0200, Oliver Neukum wrote:
> Am Montag, den 17.05.2021, 01:01 +0000 schrieb Hayes Wang:
> > Alan Stern <stern@...land.harvard.edu>
> > > Sent: Friday, May 14, 2021 11:33 PM
> 
> > > So if a peculiar emulated device created by syzbot is capable of
> > > crashing the driver, then somewhere there is a bug which needs to
> > > be
> > > fixed.  It's true that fixing all these bugs might not protect
> > > against a
> > > malicious device which deliberately behaves in an apparently
> > > reasonable
> > > manner.  But it does reduce the attack surface.
> > 
> > Thanks for your response.
> > I will add some checks.
> 
> Hi,
> 
> the problem in this particular case is in
> static bool rtl_vendor_mode(struct usb_interface *intf)
> which accepts any config number. It needs to bail out
> if you find config #0 to be what the descriptors say,
> treating that as an unrecoverable error.

No, the problem is that the routine calls WARN_ON_ONCE when it doesn't 
find an appropriate configuration.  WARN_ON_ONCE means there is a bug or 
problem in the kernel.  That's not the issue here; the issue is that the 
device doesn't have the expected descriptors.

The line should be dev_warn(), not WARN_ON_ONCE.

Alan Stern