[PATCH] usb: cdns3: Do not access memory after free

[Marek Vasut]

On 8/29/25 6:22 AM, Siddharth Vadapalli wrote:
> On Thu, Aug 28, 2025 at 05:46:56PM +0200, Marek Vasut wrote:
>> On 8/24/25 10:02 AM, Siddharth Vadapalli wrote:
>>> On Sat, Aug 23, 2025 at 02:21:18PM +0200, Marek Vasut wrote:
>>>> On 8/23/25 4:07 AM, Siddharth Vadapalli wrote:
>>>>
>>>> Hi,
>>>>
>>>>>>>>> I was planning to test this patch but the change being made is only
>>>>>>>>> applicable to Controller Versions:
>>>>>>>>> 	#define DEV_VER_NXP_V1		0x00024502
>>>>>>>>> 	#define DEV_VER_TI_V1		0x00024509
>>>>>>>>> and not to:
>>>>>>>>> 	#define DEV_VER_V2		0x0002450C
>>>>>>>>> 	#define DEV_VER_V3		0x0002450d
>>>>>>>>>
>>>>>>>>> Since I don't have an SoC and a Board with DEV_VER_TI_V1, I cannot test
>>>>>>>>> it. However, the change looks correct to me.
>>>>>>>>>
>>>>>>>>> Reviewed-by: Siddharth Vadapalli <s-vadapalli at ti.com>
>>>>>>>> The change does indeed look correct.
>>>>>>>>
>>>>>>>> Do you know who might still have that board and could test ? (and which
>>>>>>>> board/soc is that) ?
>>>>>>>
>>>>>>> None of the boards that I have worked with have a DEV_VER_TI_V1 version
>>>>>>> of the controller. I also tried to use the Linux device-tree to check if
>>>>>>> I could identify the SoC/board but I was unable to do so.
>>>>>> Do you know which SoC is V2 and V3 ?
>>>>>
>>>>> I spent more time on this and found out that J721E SR 1.0 has the
>>>>> controller with DEV_VER_TI_V1 version but other revisions of J721E as
>>>>> well as all of the following SoCs have DEV_VER_V3 version of the
>>>>> controller:
>>>>> AM64, AM68, AM69, J7200, J721S2, J722S, J742S2 and J784S4.
>>>>>
>>>>> I will try to find an SR 1.0 J721E SoC and test the patch on it and
>>>>> share the results here.
>>>> This is awesome, thank you !
>>>
>>> I was able to get an SR 1.0 J721E SoC and also the J721E
>>> Common-Processor-Board for testing the patch.
>>>
>>> Enabling debug info in the cdns3/gadget.c driver, I see:
>>> 	cdns-usb3-peripheral usb at 6000000: Device Controller version: 00024509
>>> 	cdns-usb3-peripheral usb at 6000000: USB Capabilities:: 09203324
>>> 	cdns-usb3-peripheral usb at 6000000: On-Chip memory cnfiguration: 00000c34
>>> which confirms the Controller Version.
>>>
>>> However, the code changed by the current patch is only affecting the
>>> execution of code associated with Workaround 2 which is described in
>>> detail in the driver. I am summarizing it here for your reference:
>>>
>>> Issue:
>>> 	Controller for OUT endpoints has shared on-chip buffers for all
>>> 	incoming packets. The buffer acts as a FIFO, due to which,
>>> 	missing a DMA descriptor for one packet will block subsequent
>>> 	transfers/packets meant for other Endpoints that were queued.
>>>
>>> Workaround:
>>> 	If the Endpoint Status register indicates a Descriptor Miss,
>>> 	rearm the DMA transfer to complete the missed transfer.
>>>
>>> In order to test the patch, I used USBACM for STDIO/STDOUT to check if I
>>> could trigger the descriptor miss workaround. The command I ran was:
>>> setenv stdio usbacm; setenv stdout usbacm;
>>> /dev/ttyACM0 showed up on my PC and I was also able to access the U-Boot
>>> prompt via ACM0. While it is functional, I didn't see the code
>>> associated with the workaround being triggered. Reviewing the driver
>>> again, I identified that the workaround is being disabled very early on
>>> within "cdns3_wa2_gadget_ep_queue()" with the comment stating:
>>>
>>> 	 * If transfer was queued before DESCMISS appear than we
>>> 	 * can disable handling of DESCMISS interrupt. Driver assumes that it
>>> 	 * can disable special treatment for this endpoint.
>>>
>>> Given the above, it doesn't seem easy to recreate the issue since I
>>> would have to trigger a descriptor miss event prior to the very first
>>> USB transfer for the Endpoint. Please let me know if you have any
>>> suggestions for speeding up testing.
>> Can you maybe simply force-enable the workaround code and see if that itself
>> works, without crashing ? If yes, then I would say let's apply this.
> 
> I did try it out when I wasn't able to trigger the workaround and I
> didn't see a crash. It seemed to work without issues but I didn't
> mention it since I felt that this wasn't the right way to test it.
> Nevertheless, I can confirm that I did not see a crash when forcing the
> workaround code to execute.
All right, thanks for checking, I'll pick this for 2025.10-rc4 .