linux-kernel - Re: [syzbot] [usb?] WARNING in dtv5100_i2c_msg/usb_submit

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: <CANsfzsQ7zSS2Usk3apniSvK-zfggRt-sjN-dYoLVr6+2EXtDog@mail.gmail.com>
Date: Wed, 28 May 2025 16:16:17 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Oliver Neukum <oneukum@...e.com>
Cc: syzbot <syzbot+0335df380edd9bd3ff70@...kaller.appspotmail.com>, 
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org, 
	linux-usb@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [usb?] WARNING in dtv5100_i2c_msg/usb_submit_urb

On Wed, May 28, 2025 at 9:02 AM Oliver Neukum <oneukum@...e.com> wrote:
>
> On 27.05.25 04:02, syzbot wrote:
>
> >
> > ------------[ cut here ]------------
> > usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0
> > WARNING: CPU: 0 PID: 5833 at drivers/usb/core/urb.c:413 usb_submit_urb+0x1112/0x1870 drivers/usb/core/urb.c:411
>
> [..]
> > Call Trace:
> >   <TASK>
> >   usb_start_wait_urb+0x114/0x4c0 drivers/usb/core/message.c:59
> >   usb_internal_control_msg drivers/usb/core/message.c:103 [inline]
> >   usb_control_msg+0x232/0x3e0 drivers/usb/core/message.c:154
> >   dtv5100_i2c_msg+0x250/0x330 drivers/media/usb/dvb-usb/dtv5100.c:60
> >   dtv5100_i2c_xfer+0x1a4/0x3c0 drivers/media/usb/dvb-usb/dtv5100.c:86
>
> Hi,
>
> these transfers are done via control transfers to endpoint 0.
> So this is not yet another one of those cases that a driver fails
> to verify that it operates on the intended hardware.
> I'd say that a driver can assume that endpoint 0 exists and is
> a control endpoint.
>
> But I am afraid we never check that. Should we?

That's not the problem here.  The problem is the same as in other USB
I2C drivers, and
Wolfgang Sang has been fixing them up one by one.  Namely, these
devices send I2C
messages as control transfers over ep0, and this doesn't work right
with the client asks
for a 0-length read transfer (since USB doesn't support 0-length read
control transfers,
only 0-length writes).

Alan Stern