Re: [syzbot] [usb?] WARNING in dib0700_i2c_xfer/usb_submit_urb

[Alan Stern]

On Mon, Mar 24, 2025 at 11:18:29AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    5fc319360819 Merge tag 'net-6.14-rc8' of git://git.kernel...
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=15445e98580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=27515cfdbafbb90d
> dashboard link: https://syzkaller.appspot.com/bug?extid=c38e5e60d0041a99dbf5
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13ea4c4c580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15435004580000

> ------------[ cut here ]------------
> usb 1-1: BOGUS control dir, pipe 80000f80 doesn't match bRequestType c0
> WARNING: CPU: 1 PID: 5901 at drivers/usb/core/urb.c:413 usb_submit_urb+0x11d9/0x18c0 drivers/usb/core/urb.c:411

> Call Trace:
>  <TASK>
>  usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59
>  usb_internal_control_msg drivers/usb/core/message.c:103 [inline]
>  usb_control_msg+0x2b1/0x4c0 drivers/usb/core/message.c:154
>  dib0700_ctrl_rd drivers/media/usb/dvb-usb/dib0700_core.c:95 [inline]
>  dib0700_i2c_xfer_legacy drivers/media/usb/dvb-usb/dib0700_core.c:315 [inline]
>  dib0700_i2c_xfer+0xc53/0x1060 drivers/media/usb/dvb-usb/dib0700_core.c:361
>  __i2c_transfer+0x866/0x2220
>  i2c_transfer+0x271/0x3b0 drivers/i2c/i2c-core-base.c:2315
>  i2cdev_ioctl_rdwr+0x452/0x710 drivers/i2c/i2c-dev.c:306
>  i2cdev_ioctl+0x759/0x9f0 drivers/i2c/i2c-dev.c:467
>  vfs_ioctl fs/ioctl.c:51 [inline]

It appears that this problem was caused by the fuzzer requesting an i2c 
transfer containing a 0-length read (I2C_M_RD) message.  The dib0700 
driver translates this more or less literally into a USB read request of 
length 0.  But the USB protocol does not allow such things; a 
request of length 0 is always a write.  Hence the WARNING above.

As far as I can tell from the source code, the dib0700 simply isn't able 
to handle 0-length reads.  Should the dib0700_ctrl_rd() routine be 
changed simply to return 0 in such cases?

Alan Stern