[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b12dd926-2f81-4feb-a3b0-b7fca2592909@rowland.harvard.edu>
Date: Thu, 10 Jul 2025 10:13:18 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: syzbot <syzbot+592e2ab8775dbe0bf09a@...kaller.appspotmail.com>,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
USB list <linux-usb@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [syzbot] [kernel?] INFO: task hung in uevent_show (2)
On Thu, Jul 10, 2025 at 07:17:19PM +0900, Tetsuo Handa wrote:
> On 2025/07/10 0:41, Alan Stern wrote:
> > Okay, I see what your problem is.
> >
> > The bEndpointAddress field of the endpoint descriptor is not just the
> > endpoint's number. It also includes the endpoint's direction in bit 7
> > (0 for OUT, 1 for IN).
>
> I see, but I couldn't figure out whether BUG_ON(endpoint > 0xF) is bad.
>
> I came up to try these BUG_ON() lines in case some of hung task reports (e.g.
> https://lkml.kernel.org/r/686e8032.050a0220.385921.0006.GAE@google.com ) are
> caused by use of unintended pipes created by out-of-range values being passed
> to __create_pipe().
I think this is unlikely to be the cause of those BUG_ON()s, but go
ahead and see what happens.
> Should I give up BUG_ON(endpoint > 0xF) line?
> Or should I try to update callers which trigger BUG_ON(endpoint > 0xF) line?
You can change the test to BUG_ON(endpoint & ~0x8F). That will mask
away the endpoint number and direction bit, leaving everything else
alone.
Alan Stern
Powered by blists - more mailing lists