[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a8bed564-3eec-472d-8e57-aaf5274c13b1@I-love.SAKURA.ne.jp>
Date: Thu, 10 Jul 2025 19:17:19 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Alan Stern <stern@...land.harvard.edu>
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 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().
Should I give up BUG_ON(endpoint > 0xF) line?
Or should I try to update callers which trigger BUG_ON(endpoint > 0xF) line?
Powered by blists - more mailing lists