Page 2 of 10 results (0.025 seconds)

CVSS: 9.8EPSS: 0%CPEs: 1EXPL: 1

Azure RTOS USBX is a USB host, device, and on-the-go (OTG) embedded stack, that is fully integrated with Azure RTOS ThreadX. Prior to version 6.1.12, the USB DFU UPLOAD functionality may be utilized to introduce a buffer overflow resulting in overwrite of memory contents. In particular cases this may allow an attacker to bypass security features or execute arbitrary code. The implementation of `ux_device_class_dfu_control_request` function prevents buffer overflow during handling of DFU UPLOAD command when current state is `UX_SYSTEM_DFU_STATE_DFU_IDLE`. This issue has been patched, please upgrade to version 6.1.12. • https://github.com/azure-rtos/usbx/security/advisories/GHSA-m9p8-xrp7-vvqp • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') •

CVSS: 9.8EPSS: 0%CPEs: 1EXPL: 0

Azure RTOS USBX is a high-performance USB host, device, and on-the-go (OTG) embedded stack, that is fully integrated with Azure RTOS ThreadX. The case is, in [_ux_host_class_pima_read](https://github.com/azure-rtos/usbx/blob/master/common/usbx_host_classes/src/ux_host_class_pima_read.c), there is data length from device response, returned in the very first packet, and read by [L165 code](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L165), as header_length. Then in [L178 code](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L178), there is a “if” branch, which check the expression of “(header_length - UX_HOST_CLASS_PIMA_DATA_HEADER_SIZE) > data_length” where if header_length is smaller than UX_HOST_CLASS_PIMA_DATA_HEADER_SIZE, calculation could overflow and then [L182 code](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L182) the calculation of data_length is also overflow, this way the later [while loop start from L192](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L192) can move data_pointer to unexpected address and cause write buffer overflow. The fix has been included in USBX release [6.1.12](https://github.com/azure-rtos/usbx/releases/tag/v6.1.12_rel). The following can be used as a workaround: Add check of `header_length`: 1. • https://github.com/azure-rtos/usbx/releases/tag/v6.1.12_rel https://github.com/azure-rtos/usbx/security/advisories/GHSA-gg76-h537-xq48 • CWE-191: Integer Underflow (Wrap or Wraparound) •

CVSS: 9.8EPSS: 3%CPEs: 1EXPL: 2

Azure RTOS USBx is a USB host, device, and on-the-go (OTG) embedded stack, fully integrated with Azure RTOS ThreadX and available for all Azure RTOS ThreadX–supported processors. Azure RTOS USBX implementation of host support for USB CDC ECM includes an integer underflow and a buffer overflow in the `_ux_host_class_cdc_ecm_mac_address_get` function which may be potentially exploited to achieve remote code execution or denial of service. Setting mac address string descriptor length to a `0` or `1` allows an attacker to introduce an integer underflow followed (string_length) by a buffer overflow of the `cdc_ecm -> ux_host_class_cdc_ecm_node_id` array. This may allow one to redirect the code execution flow or introduce a denial of service. The fix has been included in USBX release [6.1.12](https://github.com/azure-rtos/usbx/releases/tag/v6.1.12_rel). • https://github.com/azure-rtos/usbx/blob/master/common/usbx_host_classes/src/ux_host_class_cdc_ecm_mac_address_get.c#L264 https://github.com/azure-rtos/usbx/releases/tag/v6.1.12_rel https://github.com/azure-rtos/usbx/security/advisories/GHSA-chpp-5fv9-6368 • CWE-121: Stack-based Buffer Overflow CWE-191: Integer Underflow (Wrap or Wraparound) CWE-1284: Improper Validation of Specified Quantity in Input •

CVSS: 9.8EPSS: 2%CPEs: 1EXPL: 0

Azure RTOS USBX is a USB host, device, and on-the-go (OTG) embedded stack. Prior to version 6.1.11, he USBX DFU UPLOAD functionality may be utilized to introduce a buffer overflow resulting in overwrite of memory contents. In particular cases this may allow an attacker to bypass security features or execute arbitrary code. The implementation of `ux_device_class_dfu_control_request` function does not assure that a buffer overflow will not occur during handling of the DFU UPLOAD command. When an attacker issues the `UX_SLAVE_CLASS_DFU_COMMAND_UPLOAD` control transfer request with `wLenght` larger than the buffer size (`UX_SLAVE_REQUEST_CONTROL_MAX_LENGTH`, 256 bytes), depending on the actual implementation of `dfu -> ux_slave_class_dfu_read`, a buffer overflow may occur. • https://github.com/azure-rtos/usbx/blob/master/common/usbx_device_classes/src/ux_device_class_dfu_control_request.c https://github.com/azure-rtos/usbx/releases/tag/v6.1.11_rel https://github.com/azure-rtos/usbx/security/advisories/GHSA-hh5p-x584-j8hv • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') •

CVSS: 9.8EPSS: 0%CPEs: 1EXPL: 0

Azure RTOS USBX is a USB host, device, and on-the-go (OTG) embedded stack. In versions prior to 6.1.10, an attacker can cause a buffer overflow by providing the Azure RTOS USBX host stack a HUB descriptor with `bNbPorts` set to a value greater than `UX_MAX_TT` which defaults to 8. For a `bNbPorts` value of 255, the implementation of `ux_host_class_hub_descriptor_get` function will modify the contents of `hub` -> `ux_host_class_hub_device` -> `ux_device_hub_tt` array violating the end boundary by 255 - `UX_MAX_TT` items. The USB host stack needs to validate the number of ports reported by the hub, and if the value is larger than UX_MAX_TT, USB stack needs to reject the request. This fix has been included in USBX release 6.1.10. • https://github.com/azure-rtos/usbx/releases/tag/v6.1.10_rel https://github.com/azure-rtos/usbx/security/advisories/GHSA-2qc5-385m-x862 • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') •