From: Alan Stern <stern@rowland.harvard.edu>
To: Helge Deller <deller@gmx.de>
Cc: linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
dri-devel@lists.freedesktop.org,
syzbot <syzbot+0e22d63dcebb802b9bc8@syzkaller.appspotmail.com>,
bernie@plugable.com, linux-usb@vger.kernel.org,
syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [fbdev?] [usb?] WARNING in dlfb_submit_urb/usb_submit_urb (2)
Date: Thu, 18 May 2023 16:35:07 -0400 [thread overview]
Message-ID: <c7b8e69a-cabe-4e17-a511-66179259d1d7@rowland.harvard.edu> (raw)
In-Reply-To: <ZGZ3JPLqxCxA2UB6@ls3530>
On Thu, May 18, 2023 at 09:06:12PM +0200, Helge Deller wrote:
> * Alan Stern <stern@rowland.harvard.edu>:
> > On Thu, May 18, 2023 at 04:16:33PM +0200, Helge Deller wrote:
> > > On 5/18/23 15:54, Alan Stern wrote:
> > > > In this case it looks like dlfb_usb_probe() or one of the routines it
> > > > calls is wrong; it assumes that an endpoint has the expected type
> > > > without checking. More precisely, it thinks an endpoint is BULK when
> > > > actually it is INTERRUPT. That's what needs to be fixed.
> > >
> > > Maybe usb_submit_urb() should return an error so that drivers can
> > > react on it, instead of adding the same kind of checks to all drivers?
> >
> > Feel free to submit a patch doing this.
>
> As you wrote above, this may break other drivers too, so I'd leave that
> discussion & decision to the USB maintainers (like you).
>
> > But the checks should be added
> > in any case; without them the drivers are simply wrong.
>
> I pushed the hackish patch below through the syz tests which gives this log:
> (see https://syzkaller.appspot.com/text?tag=CrashLog&x=160b7509280000)
> [ 77.559566][ T9] usb 1-1: Unable to get valid EDID from device/display
> [ 77.587021][ T9] WARNING: BOGUS urb xfer, pipe 3 != type 1 (fix driver to choose correct endpoint)
> [ 77.596448][ T9] usb 1-1: dlfb_urb_completion - nonzero write bulk status received: -115
> [ 77.605308][ T9] usb 1-1: submit urb error: -22
> [ 77.613225][ T9] udlfb: probe of 1-1:0.52 failed with error -22
>
> So, basically there is no urgent fix needed for the dlfb fbdev driver,
> as it will gracefully fail as is (which is correct).
>
> What do you suggest we should do with this syzkaller-bug ?
> I'd rate it as false-alarm, but it will continue to complain because of
> the dev_WARN() in urb.c
Let's try this patch instead. It might contain a stupid error because I
haven't even tried to compile it, but it ought to fix the real problem.
Alan Stern
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git a4422ff22142
Index: usb-devel/drivers/video/fbdev/udlfb.c
===================================================================
--- usb-devel.orig/drivers/video/fbdev/udlfb.c
+++ usb-devel/drivers/video/fbdev/udlfb.c
@@ -1652,7 +1652,7 @@ static int dlfb_usb_probe(struct usb_int
struct fb_info *info;
int retval;
struct usb_device *usbdev = interface_to_usbdev(intf);
- struct usb_endpoint_descriptor *out;
+ static u8 out_ep[] = {1 + USB_DIR_OUT, 0};
/* usb initialization */
dlfb = kzalloc(sizeof(*dlfb), GFP_KERNEL);
@@ -1666,9 +1666,9 @@ static int dlfb_usb_probe(struct usb_int
dlfb->udev = usb_get_dev(usbdev);
usb_set_intfdata(intf, dlfb);
- retval = usb_find_common_endpoints(intf->cur_altsetting, NULL, &out, NULL, NULL);
- if (retval) {
- dev_err(&intf->dev, "Device should have at lease 1 bulk endpoint!\n");
+ if (!usb_check_bulk_endpoints(intf, out_ep)) {
+ dev_err(&intf->dev, "Invalid DisplayLink device!\n");
+ retval = -EINVAL;
goto error;
}
next prev parent reply other threads:[~2023-05-18 20:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 4:12 [syzbot] [fbdev?] [usb?] WARNING in dlfb_submit_urb/usb_submit_urb (2) syzbot
2023-05-18 7:34 ` Helge Deller
2023-05-18 7:40 ` syzbot
2023-05-18 13:54 ` Alan Stern
2023-05-18 14:16 ` Helge Deller
2023-05-18 14:56 ` Alan Stern
2023-05-18 19:06 ` Helge Deller
2023-05-18 20:35 ` Alan Stern [this message]
2023-05-18 21:08 ` syzbot
2023-05-19 10:38 ` Helge Deller
2023-05-19 15:42 ` Alan Stern
2023-05-19 18:40 ` Helge Deller
2023-05-19 19:32 ` [PATCH] video: udlfb: Fix endpoint check Alan Stern
2023-05-19 19:51 ` Helge Deller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c7b8e69a-cabe-4e17-a511-66179259d1d7@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=bernie@plugable.com \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=syzbot+0e22d63dcebb802b9bc8@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).