[syzbot] WARNING in rtl8152_probe

[syzbot] WARNING in rtl8152_probe

[syzbot]

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: syzbot+95afd23673f5dd295c57@syzkaller.appspotmail.com

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 syzkaller@googlegroups.com.

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

RE: [syzbot] WARNING in rtl8152_probe

[Hayes Wang]

syzbot <syzbot+95afd23673f5dd295c57@syzkaller.appspotmail.com>
> 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

Re: [syzbot] WARNING in rtl8152_probe

[Alan Stern]

On Thu, May 13, 2021 at 03:13:36AM +0000, Hayes Wang wrote:
> syzbot <syzbot+95afd23673f5dd295c57@syzkaller.appspotmail.com>
> > 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

RE: [syzbot] WARNING in rtl8152_probe

[Hayes Wang]

Alan Stern <stern@rowland.harvard.edu>
> 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

Re: [syzbot] WARNING in rtl8152_probe

[Dan Carpenter]

On Fri, May 14, 2021 at 02:58:00AM +0000, Hayes Wang wrote:
> Alan Stern <stern@rowland.harvard.edu>
> > 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

Re: [syzbot] WARNING in rtl8152_probe

[Greg KH]

On Fri, May 14, 2021 at 02:58:00AM +0000, Hayes Wang wrote:
> Alan Stern <stern@rowland.harvard.edu>
> > 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

RE: [syzbot] WARNING in rtl8152_probe

[Hayes Wang]

Dan Carpenter <dan.carpenter@oracle.com>
> 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

RE: [syzbot] WARNING in rtl8152_probe

[Hayes Wang]

Greg KH <greg@kroah.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?

Best Regards,
Hayes

Re: [syzbot] WARNING in rtl8152_probe

[Greg KH]

On Fri, May 14, 2021 at 07:50:19AM +0000, Hayes Wang wrote:
> Greg KH <greg@kroah.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?

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

RE: [syzbot] WARNING in rtl8152_probe

[Hayes Wang]

Greg KH <greg@kroah.com>
> 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

Re: [syzbot] WARNING in rtl8152_probe

[Alan Stern]

On Fri, May 14, 2021 at 07:50:19AM +0000, Hayes Wang wrote:
> Greg KH <greg@kroah.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

RE: [syzbot] WARNING in rtl8152_probe

[Hayes Wang]

Alan Stern <stern@rowland.harvard.edu>
> 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

Re: [syzbot] WARNING in rtl8152_probe

[Oliver Neukum]

Am Montag, den 17.05.2021, 01:01 +0000 schrieb Hayes Wang:
> Alan Stern <stern@rowland.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.

	Regards
		Oliver

Re: [syzbot] WARNING in rtl8152_probe

[Alan Stern]

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@rowland.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