In the max3420_set_clear_feature() function, the endpoint index `id` can have a value from 0 to 15. However, the udc->ep array is initialized with a maximum of 4 endpoints in max3420_eps_init(). If host sends a request with a wIndex greater than 3, the access to `udc->ep[id]` will go out-of-bounds, leading to memory corruption or a potential kernel crash. This bug was found by code inspection and has not been tested on hardware.
Fixes: 48ba02b2e2b1a ("usb: gadget: add udc driver for max3420") Cc: stable@vger.kernel.org Signed-off-by: Seungjin Bae eeodqql09@gmail.com --- drivers/usb/gadget/udc/max3420_udc.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/udc/max3420_udc.c b/drivers/usb/gadget/udc/max3420_udc.c index 7349ea774adf..e4ecc7f7f3be 100644 --- a/drivers/usb/gadget/udc/max3420_udc.c +++ b/drivers/usb/gadget/udc/max3420_udc.c @@ -596,6 +596,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);
In the max3420_set_clear_feature() function, the endpoint index `id` can have a value from 0 to 15. However, the udc->ep array is initialized with a maximum of 4 endpoints in max3420_eps_init(). If host sends a request with a wIndex greater than 3, the access to `udc->ep[id]` will go out-of-bounds, leading to memory corruption or a potential kernel crash. This bug was found by code inspection and has not been tested on hardware.
Fixes: 48ba02b2e2b1a ("usb: gadget: add udc driver for max3420") Cc: stable@vger.kernel.org Signed-off-by: Seungjin Bae eeodqql09@gmail.com --- v1 -> v2: Added a second patch to fix an out-of-bounds bug in the max3420_getstatus() function.
drivers/usb/gadget/udc/max3420_udc.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/udc/max3420_udc.c b/drivers/usb/gadget/udc/max3420_udc.c index 7349ea774adf..e4ecc7f7f3be 100644 --- a/drivers/usb/gadget/udc/max3420_udc.c +++ b/drivers/usb/gadget/udc/max3420_udc.c @@ -596,6 +596,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);
On Sun, Jun 29, 2025 at 05:49:45PM -0400, Seungjin Bae wrote:
In the max3420_set_clear_feature() function, the endpoint index `id` can have a value from 0 to 15. However, the udc->ep array is initialized with a maximum of 4 endpoints in max3420_eps_init(). If host sends a request with a wIndex greater than 3, the access to `udc->ep[id]` will go out-of-bounds, leading to memory corruption or a potential kernel crash. This bug was found by code inspection and has not been tested on hardware.
Please wrap your lines at 72 columns.
Also, you sent 2 patches, with identical subject lines, but they did different things. That's not ok as you know.
And I think you really need to test this on hardware. How could that request ever have a windex set to greater than 3? Is that a hardware value or a user-controlled value?
thanks,
greg k-h
Also, you sent 2 patches, with identical subject lines, but they did different things. That's not ok as you know.
My apologies for the mistake. I will separate them properly in the next version of the patch series.
And I think you really need to test this on hardware. How could that request ever have a windex set to greater than 3? Is that a hardware value or a user-controlled value?
The wIndex field of a SETUP packet is sent by the USB host and can be controlled by a malicious or malformed host. This same class of vulnerability was identified and fixed in other UDC drivers, as described in CVE-2022-27223 and fixed in the xilinx UDC driver by commit 7f14c7227f34 ("USB: gadget: validate endpoint index for xilinx udc").
Following this established pattern, I added the necessary bounds check to the max3420_udc driver before wIndex is used to access the endpoint array.
Thank you.
Seungjin Bae
Similar to max3420_set_clear_feature() function, the max3420_getstatus() function also fails to validate the endpoint index from wIndex before using it to access the udc->ep array.
The udc->ep array is initialized to handle 4 endpoints, but the index derived from the `wIndex & USB_ENDPOINT_NUMBER_MASK` can be up to 15. This can lead to an out-of-bounds access, causing memory corruption or a potential kernel crash. This bug was found by code inspection and has not been tested on hardware.
Fixes: 48ba02b2e2b1a ("usb: gadget: add udc driver for max3420") Cc: stable@vger.kernel.org Signed-off-by: Seungjin Bae eeodqql09@gmail.com --- v1 -> v2: Added a second patch to fix an out-of-bounds bug in the max3420_getstatus() function.
drivers/usb/gadget/udc/max3420_udc.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/max3420_udc.c b/drivers/usb/gadget/udc/max3420_udc.c index e4ecc7f7f3be..ff6c7f9d71d8 100644 --- a/drivers/usb/gadget/udc/max3420_udc.c +++ b/drivers/usb/gadget/udc/max3420_udc.c @@ -536,6 +536,7 @@ static void max3420_getstatus(struct max3420_udc *udc) { struct max3420_ep *ep; u16 status = 0; + int id;
switch (udc->setup.bRequestType & USB_RECIP_MASK) { case USB_RECIP_DEVICE: @@ -548,7 +549,10 @@ static void max3420_getstatus(struct max3420_udc *udc) goto stall; break; case USB_RECIP_ENDPOINT: - ep = &udc->ep[udc->setup.wIndex & USB_ENDPOINT_NUMBER_MASK]; + id = udc->setup.wIndex & USB_ENDPOINT_NUMBER_MASK; + if (id >= MAX3420_MAX_EPS) + goto stall; + ep = &udc->ep[id]; if (udc->setup.wIndex & USB_DIR_IN) { if (!ep->ep_usb.caps.dir_in) goto stall;
linux-stable-mirror@lists.linaro.org
-
Greg Kroah-Hartman -
pip-izony -
Seungjin Bae