Hello,
syzbot found the following issue on:
HEAD commit: d665ea6e Merge tag 'for-linus-5.13-rc1' of git://git.kerne..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=10ae6ff5d00000
kernel config: https://syzkaller.appspot.com/x/.config?x=f635d6ce17da8a68
dashboard link: https://syzkaller.appspot.com/bug?extid=95afd23673f5dd295c57
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14a35733d00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1621d7b9d00000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
usb 1-1: New USB device found, idVendor=045e, idProduct=0927, bcdDevice=89.4f
usb 1-1: New USB device strings: Mfr=0, Product=4, SerialNumber=0
usb 1-1: Product: syz
usb 1-1: config 0 descriptor??
------------[ cut here ]------------
WARNING: CPU: 1 PID: 32 at drivers/net/usb/r8152.c:8138 rtl_vendor_mode drivers/net/usb/r8152.c:8138 [inline]
WARNING: CPU: 1 PID: 32 at drivers/net/usb/r8152.c:8138 rtl8152_probe+0x248/0x3050 drivers/net/usb/r8152.c:9381
Modules linked in:
CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 5.12.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:rtl_vendor_mode drivers/net/usb/r8152.c:8138 [inline]
RIP: 0010:rtl8152_probe+0x248/0x3050 drivers/net/usb/r8152.c:9381
Code: c3 a8 02 00 00 89 ee e8 26 bf c5 fd 41 39 ed 0f 85 40 ff ff ff e8 58 b9 c5 fd 44 89 ee 44 89 ef e8 0d bf c5 fd e8 48 b9 c5 fd <0f> 0b 41 bc ed ff ff ff e8 3b b9 c5 fd 44 89 e0 48 83 c4 40 5b 5d
RSP: 0018:ffffc900001a7178 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8881191ceaa8 RCX: 0000000000000000
RDX: ffff888107fe8000 RSI: ffffffff837b33c8 RDI: 0000000000000003
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000002
R10: ffffffff837b33c3 R11: 00000000ffffffff R12: dffffc0000000000
R13: 0000000000000001 R14: ffff8881191660a8 R15: 0000000000000002
FS: 0000000000000000(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004b30f0 CR3: 000000010a0c8000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
really_probe+0x291/0xf60 drivers/base/dd.c:576
driver_probe_device+0x298/0x410 drivers/base/dd.c:763
__device_attach_driver+0x203/0x2c0 drivers/base/dd.c:870
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
__device_attach+0x228/0x4b0 drivers/base/dd.c:938
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
device_add+0xbe0/0x2100 drivers/base/core.c:3319
usb_set_configuration+0x113f/0x1910 drivers/usb/core/message.c:2164
usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293
really_probe+0x291/0xf60 drivers/base/dd.c:576
driver_probe_device+0x298/0x410 drivers/base/dd.c:763
__device_attach_driver+0x203/0x2c0 drivers/base/dd.c:870
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
__device_attach+0x228/0x4b0 drivers/base/dd.c:938
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
device_add+0xbe0/0x2100 drivers/base/core.c:3319
usb_new_device.cold+0x721/0x1058 drivers/usb/core/hub.c:2556
hub_port_connect drivers/usb/core/hub.c:5276 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5416 [inline]
port_event drivers/usb/core/hub.c:5562 [inline]
hub_event+0x2357/0x4320 drivers/usb/core/hub.c:5644
process_one_work+0x98d/0x1580 kernel/workqueue.c:2275
worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
kthread+0x38c/0x460 kernel/kthread.c:313
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
syzbot <[email protected]>
> Sent: Wednesday, May 12, 2021 5:40 PM
[...]
> usb 1-1: New USB device found, idVendor=045e, idProduct=0927, bcdDevice=89.4f
> usb 1-1: New USB device strings: Mfr=0, Product=4, SerialNumber=0
> usb 1-1: Product: syz
> usb 1-1: config 0 descriptor??
The bcdDevice is strange. Could you dump your USB descriptor?
My log is as following.
[root@fc32 r8152_inbox]# dmesg
[ 2174.703974] usb 2-8: new SuperSpeed Gen 1 USB device number 7 using xhci_hcd
[ 2174.716592] usb 2-8: New USB device found, idVendor=045e, idProduct=0927, bcdDevice=31.00
[ 2174.716604] usb 2-8: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 2174.716609] usb 2-8: Product: USB 10/100/1000 LAN
[ 2174.716613] usb 2-8: Manufacturer: Realtek
[ 2174.716617] usb 2-8: SerialNumber: 0010010AA
[ 2174.837277] usb 2-8: reset SuperSpeed Gen 1 USB device number 7 using xhci_hcd
[ 2174.869013] r8152 2-8:1.0: load rtl8153b-2 v1 10/23/19 successfully
[ 2174.897836] r8152 2-8:1.0 eth2: v1.12.11
[root@fc32 r8152_inbox]# ethtool -i eth2
driver: r8152
version: v1.12.11
firmware-version: rtl8153b-2 v1 10/23/19
expansion-rom-version:
bus-info: usb-0000:00:14.0-8
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
[root@fc32 r8152_inbox]# lsusb -vd 045e:0927
Bus 002 Device 007: ID 045e:0927 Microsoft Corp. RTL8153B GigE [Surface Ethernet Adapter]
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x045e Microsoft Corp.
idProduct 0x0927 RTL8153B GigE [Surface Ethernet Adapter]
bcdDevice 31.00
iManufacturer 1 Realtek
iProduct 2 USB 10/100/1000 LAN
iSerial 6 0010010AA
bNumConfigurations 2
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0039
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 288mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 3
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 3
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 8
bMaxBurst 0
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0062
bNumInterfaces 2
bConfigurationValue 2
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 288mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 6 Ethernet Networking
bInterfaceProtocol 0
iInterface 5 CDC Communications Control
CDC Header:
bcdCDC 1.10
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Ethernet:
iMacAddress 3 00E04C660016
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1514
wNumberMCFilters 0x0000
bNumberPowerFilters 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 8
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 4 Ethernet Data
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 3
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 3
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 0x0016
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000002
HIRD Link Power Management (LPM) Supported
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x02
Latency Tolerance Messages (LTM) Supported
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 2
Lowest fully-functional device speed is High Speed (480Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 2047 micro seconds
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0010
(Bus Powered)
Latency Tolerance Messaging (LTM) Enabled
[root@fc32 r8152_inbox]#
Best Regards,
Hayes
On Thu, May 13, 2021 at 03:13:36AM +0000, Hayes Wang wrote:
> syzbot <[email protected]>
> > Sent: Wednesday, May 12, 2021 5:40 PM
> [...]
> > usb 1-1: New USB device found, idVendor=045e, idProduct=0927, bcdDevice=89.4f
> > usb 1-1: New USB device strings: Mfr=0, Product=4, SerialNumber=0
> > usb 1-1: Product: syz
> > usb 1-1: config 0 descriptor??
>
> The bcdDevice is strange. Could you dump your USB descriptor?
Syzbot doesn't test real devices. It tests emulations, and the emulated
devices usually behave very strangely and in very peculiar and
unexpected ways, so as to trigger bugs in the kernel. That's why the
USB devices you see in syzbot logs usually have bizarre descriptors.
Alan Stern
Alan Stern <[email protected]>
> Sent: Thursday, May 13, 2021 10:26 PM
[...]
> Syzbot doesn't test real devices. It tests emulations, and the emulated
> devices usually behave very strangely and in very peculiar and
> unexpected ways, so as to trigger bugs in the kernel. That's why the
> USB devices you see in syzbot logs usually have bizarre descriptors.
Do you mean I have to debug for a device which doesn't exist?
I don't understand why I must consider a fake device
which provide unexpected USB descriptor deliberately?
Best Regards,
Hayes
Dan Carpenter <[email protected]>
> Sent: Friday, May 14, 2021 2:42 PM
[...]
> Imagine you are at a conference and two people sit down next to you, one
> on either side. The one accidentally spills coffee on your lap. The
> other plugs in a USB device to your laptop. Now you are infected with
> spyware.
I don't think I could find out such devices by only checking the information
of the hardware. That is, there is no way now to avoid other devices to
use our driver.
Best Regards,
Hayes
Greg KH <[email protected]>
> 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?
Best Regards,
Hayes
On Fri, May 14, 2021 at 07:50:19AM +0000, Hayes Wang wrote:
> Greg KH <[email protected]>
> > 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?
Checking the whole USB decriptor is fine, yes, they can duplicate that.
So that means you need to validate _ALL_ data coming from the device
that it is in an acceptable range of values that the driver can
correctly handle.
thanks,
greg k-h
Greg KH <[email protected]>
> Sent: Friday, May 14, 2021 4:27 PM
[...]
> Checking the whole USB decriptor is fine, yes, they can duplicate that.
> So that means you need to validate _ALL_ data coming from the device
> that it is in an acceptable range of values that the driver can
> correctly handle.
I see.
Best Regards,
Hayes
On Fri, May 14, 2021 at 02:58:00AM +0000, Hayes Wang wrote:
> Alan Stern <[email protected]>
> > Sent: Thursday, May 13, 2021 10:26 PM
> [...]
> > Syzbot doesn't test real devices. It tests emulations, and the emulated
> > devices usually behave very strangely and in very peculiar and
> > unexpected ways, so as to trigger bugs in the kernel. That's why the
> > USB devices you see in syzbot logs usually have bizarre descriptors.
>
> Do you mean I have to debug for a device which doesn't exist?
> I don't understand why I must consider a fake device
> which provide unexpected USB descriptor deliberately?
Imagine you are at a conference and two people sit down next to you, one
on either side. The one accidentally spills coffee on your lap. The
other plugs in a USB device to your laptop. Now you are infected with
spyware.
https://elie.net/blog/security/what-are-malicious-usb-keys-and-how-to-create-a-realistic-one/
regards,
dan carpenter
On Fri, May 14, 2021 at 02:58:00AM +0000, Hayes Wang wrote:
> Alan Stern <[email protected]>
> > Sent: Thursday, May 13, 2021 10:26 PM
> [...]
> > Syzbot doesn't test real devices. It tests emulations, and the emulated
> > devices usually behave very strangely and in very peculiar and
> > unexpected ways, so as to trigger bugs in the kernel. That's why the
> > USB devices you see in syzbot logs usually have bizarre descriptors.
>
> Do you mean I have to debug for a device which doesn't exist?
> I don't understand why I must consider a fake device
> which provide unexpected USB descriptor deliberately?
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.
thanks,
greg k-h
On Fri, May 14, 2021 at 07:50:19AM +0000, Hayes Wang wrote:
> Greg KH <[email protected]>
> > 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
Alan Stern <[email protected]>
> Sent: Friday, May 14, 2021 11:33 PM
[...]
> 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.
Thanks for your response.
I will add some checks.
Best Regards,
Hayes
Am Montag, den 17.05.2021, 01:01 +0000 schrieb Hayes Wang:
> Alan Stern <[email protected]>
> > 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.
Regards
Oliver
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 <[email protected]>
> > > 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