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

Date:   Fri, 14 May 2021 11:32:53 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Hayes Wang <hayeswang@...ltek.com>
Cc:     Greg KH <greg@...ah.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 Fri, May 14, 2021 at 07:50:19AM +0000, Hayes Wang wrote:
> Greg KH <greg@...ah.com>
> > Sent: Friday, May 14, 2021 2:49 PM
> [...]
> > Because people can create "bad" devices and plug them into a system
> > which causes the driver to load and then potentially crash the system or
> > do other bad things.
> > 
> > USB drivers now need to be able to handle "malicious" devices, it's been
> > that way for many years now.
> 
> My question is that even I check whole the USB descriptor, the malicious
> devices could duplicate it easily to pass my checks. That is, I could add a
> lot of checks, but it still doesn't prevent malicious devices. Is this meaningful?

The real motivation here, which nobody has mentioned explicitly yet, is 
that the driver needs to be careful enough that it won't crash no matter 
what bizarre, malfunctioning, or malicious device is attached.

Even if a device isn't malicious, if it is buggy, broken, or 
malfunctioning in some way then it can present input that a normal 
device would never generate.  If the driver isn't prepared to handle 
this unusual input, it may crash.  That is specifically what we want to 
avoid.

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.

Alan Stern