Potential access after "free"

[jovere]

I don't have a full setup or reproduction of the issue, because I found it on a code review on a different project. It is in regards to the code linked below:

STM32CubeF4/Projects/STM324x9I_EVAL/Applications/LwIP/LwIP_UDP_Echo_Client/Src/ethernetif.c

Line 430 in b955779

dmarxdesc = (ETH_DMADescTypeDef *)(dmarxdesc->Buffer2NextDescAddr);

From what I understand in the above linked code, the buffer is being "freed" back to the DMA on line 429 and then being accessed again on line 430. What would happen if a DMA interrupt were to occur between these two lines of code? It appears to me that this has the potential to point to the wrong buffer causing memory leaks or other issues. A safe version of lines 429-430 would be as follows:

    __IO ETH_DMADescTypeDef *next = (ETH_DMADescTypeDef *)(dmarxdesc->Buffer2NextDescAddr);
    dmarxdesc->Status |= ETH_DMARXDESC_OWN;
    dmarxdesc = next;

This code appares to be implemented in many other cube libraries as well.

[RKOUSTM]

Hi @jovere,

Thank you for contribution. It has been transferred to our technical teams. We will be back to you as soon as we get an answer. Thank you for you again for your contribution.

With regards

[RKOUSTM]

Hi @jovere,

I hope you are fine. Sorry for the delay it may take sometimes to answer. The new version of the ETH HAL driver in the frame of a future release will take this update into consideration.

Thank you again for this contribution and thank you in advance for your patience. We will keep you informed.

With regards,

[RKOUSTM]

Hi @jovere,

Thank you for your contribution. A reworked ETH HAL driver and an updated ethernetif.c file are now available in the frame of the STM32CubeF4 v1.27.0. This new ETH HAL driver breaks the compatibility with the previous one.

Please allow me then to close this issue. Thank you again for your contribution. We are looking forward to reading your feedback.

With regards,