Describe the set-up
The board: STM32F769I_EVAL and STM32F769I-Discovery.
IDE or at least the compiler and its version: Not compiler-specific. Applies to STM32CubeF7 revision c2ecfd2.
Describe the bug
DynWebPage() appends fixed HTML and an unbounded FreeRTOS/CMSIS task list to a fixed 512-byte buffer (PAGE_BODY[512]). After approximately 20-30 tasks, the generated task-list output exceeds the remaining buffer space, leading to a stack buffer overflow that corrupts the web-server task stack. Because this allows direct overwriting of the stack, it can result in an arbitrary control-flow hijack and arbitrary code execution within the context of the web-server task. It affects 2 different demos but i am just reporting one issue. Please make sure to fix both. If required i can open another one.
This affects two components:
- Projects/STM32F769I_EVAL/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS/Src/httpserver-netconn.c, DynWebPage
- Projects/STM32F769I_EVAL/Applications/LwIP/LwIP_HTTP_Server_Socket_RTOS/Src/httpserver-socket.c, DynWebPage()
How To Reproduce
Global behavior of your application project: Running the LwIP HTTP Server (Netconn or Socket) RTOS example applications.
The modules that you suspect to be the cause of the problem: Application code / LwIP examples (httpserver-netconn.c and httpserver-socket.c).
The use case that generates the problem: Making an HTTP request for the dynamic task-status page when 20-30 FreeRTOS tasks exist, which exceeds the buffer capacity.
How we can reproduce the problem: Enable task-status formatting and run 20-30 FreeRTOS tasks so the generated table plus HTML exceeds 512 bytes. Request the dynamic task page.
Additional context
The caller owns a 512-byte destination buffer but delegates formatting to an API that is not given that destination's remaining size. The code uses strcat() and subsequently calls osThreadList(PAGE_BODY + strlen(PAGE_BODY)) without passing or verifying the remaining capacity. Subsequent strcat() calls are also unbounded. Alternatively, you can check if there are too many tasks before calling the function.
Patch proposal / Recommended fix:
Use a bounded formatter/API that accepts the remaining size. Track a write cursor and the remaining capacity for every append operation, and reject or truncate the task-list output if it exceeds the bounds.
Describe the set-up
The board: STM32F769I_EVAL and STM32F769I-Discovery.
IDE or at least the compiler and its version: Not compiler-specific. Applies to STM32CubeF7 revision c2ecfd2.
Describe the bug
DynWebPage() appends fixed HTML and an unbounded FreeRTOS/CMSIS task list to a fixed 512-byte buffer (PAGE_BODY[512]). After approximately 20-30 tasks, the generated task-list output exceeds the remaining buffer space, leading to a stack buffer overflow that corrupts the web-server task stack. Because this allows direct overwriting of the stack, it can result in an arbitrary control-flow hijack and arbitrary code execution within the context of the web-server task. It affects 2 different demos but i am just reporting one issue. Please make sure to fix both. If required i can open another one.
This affects two components:
How To Reproduce
Global behavior of your application project: Running the LwIP HTTP Server (Netconn or Socket) RTOS example applications.
The modules that you suspect to be the cause of the problem: Application code / LwIP examples (httpserver-netconn.c and httpserver-socket.c).
The use case that generates the problem: Making an HTTP request for the dynamic task-status page when 20-30 FreeRTOS tasks exist, which exceeds the buffer capacity.
How we can reproduce the problem: Enable task-status formatting and run 20-30 FreeRTOS tasks so the generated table plus HTML exceeds 512 bytes. Request the dynamic task page.
Additional context
The caller owns a 512-byte destination buffer but delegates formatting to an API that is not given that destination's remaining size. The code uses strcat() and subsequently calls osThreadList(PAGE_BODY + strlen(PAGE_BODY)) without passing or verifying the remaining capacity. Subsequent strcat() calls are also unbounded. Alternatively, you can check if there are too many tasks before calling the function.
Patch proposal / Recommended fix:
Use a bounded formatter/API that accepts the remaining size. Track a write cursor and the remaining capacity for every append operation, and reject or truncate the task-list output if it exceeds the bounds.