[PATCH] USB: gadget: validate endpoint index for max3420 udc

[PATCH] USB: gadget: validate endpoint index for max3420 udc

[Kery Qi]

The max3420_getstatus() and max3420_set_clear_feature() functions use
the endpoint index from USB setup packet's wIndex field to access the
endpoint array. The index is masked with USB_ENDPOINT_NUMBER_MASK (0x0f),
which allows values 0-15, but the endpoint array (udc->ep) only has
MAX3420_MAX_EPS (4) elements.

A malicious USB host can send a specially crafted control request with
an invalid endpoint index (>= 4) to trigger an out-of-bounds array access,
potentially leading to information disclosure or kernel memory corruption.

Add validation to ensure the endpoint index is within bounds before
accessing the endpoint array.

Fixes: 48ba02b2e2b1a ("usb: gadget: add udc driver for max3420")
Signed-off-by: Kery Qi <qikeyu2017@gmail.com>
---
 drivers/usb/gadget/udc/max3420_udc.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/gadget/udc/max3420_udc.c b/drivers/usb/gadget/udc/max3420_udc.c
index 7349ea774adf..9d183a986380 100644
--- a/drivers/usb/gadget/udc/max3420_udc.c
+++ b/drivers/usb/gadget/udc/max3420_udc.c
@@ -548,6 +548,9 @@ static void max3420_getstatus(struct max3420_udc *udc)
 			goto stall;
 		break;
 	case USB_RECIP_ENDPOINT:
+		if ((udc->setup.wIndex & USB_ENDPOINT_NUMBER_MASK)
+				>= MAX3420_MAX_EPS)
+			goto stall;
 		ep = &udc->ep[udc->setup.wIndex & USB_ENDPOINT_NUMBER_MASK];
 		if (udc->setup.wIndex & USB_DIR_IN) {
 			if (!ep->ep_usb.caps.dir_in)
@@ -596,6 +599,8 @@ static void max3420_set_clear_feature(struct max3420_udc *udc)
 			break;
 
 		id = udc->setup.wIndex & USB_ENDPOINT_NUMBER_MASK;
+		if (id >= MAX3420_MAX_EPS)
+			break;
 		ep = &udc->ep[id];
 
 		spin_lock_irqsave(&ep->lock, flags);
-- 
2.34.1

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

[Greg KH]

On Thu, Jan 22, 2026 at 04:39:45AM +0800, Kery Qi wrote:
> The max3420_getstatus() and max3420_set_clear_feature() functions use
> the endpoint index from USB setup packet's wIndex field to access the
> endpoint array. The index is masked with USB_ENDPOINT_NUMBER_MASK (0x0f),
> which allows values 0-15, but the endpoint array (udc->ep) only has
> MAX3420_MAX_EPS (4) elements.
> 
> A malicious USB host can send a specially crafted control request with
> an invalid endpoint index (>= 4) to trigger an out-of-bounds array access,
> potentially leading to information disclosure or kernel memory corruption.
> 
> Add validation to ensure the endpoint index is within bounds before
> accessing the endpoint array.

We've been through this before, please read the archives for the last
time this was attempted to be submitted, and go and fix the tool you are
using to find these.

thanks,

greg k-h

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

[Kery Qi]

Hi greg k-h,

Thank you for your response.

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.

If there was a previous discussion about this specific driver that I
missed, I would appreciate a pointer to that thread.

Thanks,

Kery

Greg KH <gregkh@linuxfoundation.org> 于2026年1月22日周四 13:32写道：
>
> On Thu, Jan 22, 2026 at 04:39:45AM +0800, Kery Qi wrote:
> > The max3420_getstatus() and max3420_set_clear_feature() functions use
> > the endpoint index from USB setup packet's wIndex field to access the
> > endpoint array. The index is masked with USB_ENDPOINT_NUMBER_MASK (0x0f),
> > which allows values 0-15, but the endpoint array (udc->ep) only has
> > MAX3420_MAX_EPS (4) elements.
> >
> > A malicious USB host can send a specially crafted control request with
> > an invalid endpoint index (>= 4) to trigger an out-of-bounds array access,
> > potentially leading to information disclosure or kernel memory corruption.
> >
> > Add validation to ensure the endpoint index is within bounds before
> > accessing the endpoint array.
>
> We've been through this before, please read the archives for the last
> time this was attempted to be submitted, and go and fix the tool you are
> using to find these.
>
> thanks,
>
> greg k-h

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

[Greg KH]

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