From: Greg KH <gregkh@linuxfoundation.org>
To: Kery Qi <qikeyu2017@gmail.com>
Cc: balbi@kernel.org, jaswinder.singh@linaro.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB: gadget: validate endpoint index for max3420 udc
Date: Thu, 22 Jan 2026 11:35:36 +0100 [thread overview]
Message-ID: <2026012222-unroasted-willing-6add@gregkh> (raw)
In-Reply-To: <CALEuBanDC_8YfPsbh6P-S4aBwih3WqofOg+3oN6PwF+noeyRdg@mail.gmail.com>
On Thu, Jan 22, 2026 at 06:16:08PM +0800, Kery Qi wrote:
> Hi greg k-h,
>
> Thank you for your response.
Please do not top-post, you have lost the context in this message :(
> I'd like to clarify that I found this issue by performing variant analysis
> based on commit 7f14c7227f342d9932f9b918893c8814f86d2a0d ("USB: gadget:
> validate endpoint index for xilinx udc"). That commit fixed the missing
> endpoint index validation in udc-xilinx.c before accessing the endpoint
> array, and was accepted into the kernel. I searched for similar patterns
> in other UDC drivers and found that max3420_udc.c has the same issue -
> MAX3420_MAX_EPS is only 4 while USB_ENDPOINT_NUMBER_MASK allows values
> 0-15, so both max3420_getstatus() and max3420_set_clear_feature() can
> access udc->ep[] out of bounds without validation.
But can that ever actually happen? Remember, we trust the hardware
here. if you wish to change the model where we do not trust the
hardware of this device, then there is a lot more work that needs to be
done than just attempting to add this single check.
How was this tested?
> If there was a previous discussion about this specific driver that I
> missed, I would appreciate a pointer to that thread.
I think the archives have them for this type of change, a simple search
brings up this thread:
https://lore.kernel.org/all/20250629201324.30726-4-eeodqql09@gmail.com/
It was rejected back then, please work with your teammates on
coordinating this type of thing and do not send duplicate patches.
Also, you forgot to document the tools that you used to "find" this
issue, as is required. For that reason alone this patch would not be
acceptable, sorry.
thanks,
greg k-h
prev parent reply other threads:[~2026-01-22 10:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 20:39 [PATCH] USB: gadget: validate endpoint index for max3420 udc Kery Qi
2026-01-22 5:32 ` Greg KH
2026-01-22 10:16 ` Kery Qi
2026-01-22 10:35 ` Greg KH [this message]
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=2026012222-unroasted-willing-6add@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=balbi@kernel.org \
--cc=jaswinder.singh@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=qikeyu2017@gmail.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