linux-kernel - Re: [syzbot] [usb?] WARNING in gl861_ctrl_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: <20250426131356.764288-1-n.zhandarovich@fintech.ru>
Date: Sat, 26 Apr 2025 16:13:53 +0300
From: Nikita Zhandarovich <n.zhandarovich@...tech.ru>
To: syzbot <syzbot+721071c10f3c7e4e5dcb@...kaller.appspotmail.com>
CC: Nikita Zhandarovich <n.zhandarovich@...tech.ru>,
	<syzkaller-bugs@...glegroups.com>, <linux-kernel@...r.kernel.org>,
	<linux-usb@...r.kernel.org>, Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [syzbot] [usb?] WARNING in gl861_ctrl_msg/usb_submit_urb

Hi,

> ------------[ cut here ]------------
> usb 2-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0
> WARNING: CPU: 0 PID: 5845 at drivers/usb/core/urb.c:413 usb_submit_urb+0x11dd/0x18c0 drivers/usb/core/urb.c:411
> Modules linked in:
> CPU: 0 UID: 0 PID: 5845 Comm: syz-executor566 Not tainted 6.15.0-rc2-syzkaller-00488-g6fea5fabd332 #0 PREEMPT(full) 
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
> RIP: 0010:usb_submit_urb+0x11dd/0x18c0 drivers/usb/core/urb.c:411
> ...
> Call Trace:
>  <TASK>
>  usb_start_wait_urb+0x11a/0x530 drivers/usb/core/message.c:59
>  usb_internal_control_msg drivers/usb/core/message.c:103 [inline]
>  usb_control_msg+0x2b3/0x4c0 drivers/usb/core/message.c:154
>  gl861_ctrl_msg+0x332/0x6f0 drivers/media/usb/dvb-usb-v2/gl861.c:58
>  gl861_i2c_master_xfer+0x3b4/0x650 drivers/media/usb/dvb-usb-v2/gl861.c:144
>  __i2c_transfer+0x859/0x2250 drivers/i2c/i2c-core-base.c:-1
> ...

This issue seems similar to another one [1], syzkaller managing to
craft a I2C transfer request with 0-length read message. That
request is moved to 0-length USB read request, which is forbidden.

Alan suggested a fix [2] to issue [1]. I guess it makes sense to
do something similar here as well. Unless there is a consensus
about checking for such cases deeper in I2C core?

[1] https://syzkaller.appspot.com/bug?extid=c38e5e60d0041a99dbf5
[2] https://lore.kernel.org/all/c7f67d3b-f1e6-4d68-99aa-e462fdcb315f@rowland.harvard.edu/


Regards,
Nikita