Buffer overflow in TFTP server

[Arslan8]

Describe the set-up

• The board: STM32F769I_EVAL
• IDE or at least the compiler and its version: arm-none-eabi-gcc v13

Describe the bug
A stack buffer overflow occurs in the IAP TFTP write-request (WRQ) handler. The path scans a client-controlled filename without a length limit, copies it into a fixed filename[40] array, and then formats it into a fixed message buffer using sprintf.

How To Reproduce

1. Indicate the global behavior of your application project:
   In-Application Programming (IAP) via LwIP TFTP server. The vulnerability is exposed when the application is compiled with USE_LCD enabled.

2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...):
   Middleware/Application: LwIP_IAP
   File: Projects/STM32F769I_EVAL/Applications/LwIP/LwIP_IAP/Src/tftpserver.c

3. The use case that generates the problem:
   Receiving a remote TFTP WRQ containing a filename that exceeds the fixed capacity of the destination buffer.

4. How we can reproduce the problem:

   • Build the project with USE_LCD enabled.
   • Submit a remote TFTP WRQ where the filename is longer than the fixed filename[40] capacity.
   • The application scans for the first NUL byte in the packet without bounds checking, and strncpy(filename, ptr, i + 1) executes without a destination-size bound, resulting in stack memory corruption.

Additional context

• Impact: This memory corruption is potentially severe because the affected application handles flash programming operations.
• Affected Revision: STM32CubeF7 revision c2ecfd2d
• Proposed Fix / Root Cause Analysis: The root cause is the lack of a destination-size bound during the NUL scan and string copy. To remediate this, use the pbuf payload length as a hard bound while finding the NUL byte, explicitly reject names that do not fit the filename buffer, and replace sprintf with a bounded formatter such as snprintf.