Host sending vendor specific setup request 0x00 can cause crash if vendor function request callback not registered

[TrestleMonkey]

I've implemented a basic device only CDC-ACM on my target but if a host connects using an incorrect driver, e.g. CP210x, that happens to send a vendor specific setup request code of 0x00, then my target hard-faults due to a function call to null.

The error happens in ux_device_stack_control_request_process.c : The host is sending a request type that matches UX_REQUEST_TYPE_VENDOR, and the request code (from offset UX_SETUP_REQUEST) is 0x00, which happens to be the default value of _ux_system_slave->ux_system_slave_device_vendor_request. This then results in a call to _ux_system_slave->ux_system_slave_device_vendor_request_function(...) which is NULL since I don't need this and therefore haven't called _ux_device_stack_microsoft_extension_register(). Should there be a null check on this function pointer before attempting to call it?

I can work around by calling _ux_device_stack_microsoft_extension_register(0xffffffff, NULL); during init which I think will never match an actual vendor request code.

• Target: STM32U5
• AzureRTOS v6.1.9
• Toolset: Keil MDK (USB boilerplate code initially generated from STM32CubeIDE)

To Reproduce Steps to reproduce the behavior:

1. Create/open sample USB CDC-ACM project with STM32CubeMX/IDE.
2. On the host PC, force it to use the CP210x driver for the USB connection.
3. When the host attempts to open the connection, the CP210x driver sends a vendor specific setup code which invokes the error.

Expected behavior If the vendor request function is not registered (since it is not needed) then default behaviour shouldn't attempt to call the vendor request function.

Impact Annoyance

[xiaocq2001]

Thanks for the feedback, we will fix it.

Proposed fix: Vendor request code is checked when callback is not NULL.

[xiaocq2001]

Fixed in latest release.