linux-kernel - Re: [PATCH] USB: gadget: validate endpoint index for max3420 udc

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2026012222-unroasted-willing-6add@gregkh>
Date: Thu, 22 Jan 2026 11:35:36 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Kery Qi <qikeyu2017@...il.com>
Cc: balbi@...nel.org, jaswinder.singh@...aro.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: gadget: validate endpoint index for max3420 udc

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