[Bug] OOB write in OpenAMP virtual UART RX ring buffer on stm32mp157a-st-ev1
Los mantenedores suelen responder en 1 día
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- c
Línea de trabajo
Comienza en el BSP de STM32MP157A-ST-EV1, en drv_openamp.c, en VIRT_UART0_RxCpltCallback() y _read(), y después revisa cómo VIRT_UART_read_cb() pasa los datos de rpmsg al callback de RX. Reproduce el problema con escrituras controladas en /dev/ttyRPMSG0, incluida una escritura de 255 bytes seguida de una escritura de 2 bytes. Se considera terminado cuando el anillo RX no puede escribir más allá de su búfer, la condición de wrap de lectura es segura y la reproducción ya no causa corrupción ni un fault.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
RT-Thread Version
master at commit fe548e1505
Hardware Type/Architectures
STM32MP157A-ST-EV1 BSP with BSP_USING_OPENAMP enabled.
Develop Toolchain
GCC
Describe the bug
There is a reachable memory-safety issue in the OpenAMP virtual UART receive path of the stm32mp157a-st-ev1 BSP.
VIRT_UART_read_cb() receives rpmsg data from the OpenAMP peer and forwards the externally controlled payload pointer and length into the registered RX callback:
huart->pRxBuffPtr = data;
huart->RxXferSize = len;
huart->RxCpltCallback(huart);
In this BSP, the registered callback is VIRT_UART0_RxCpltCallback() in drv_openamp.c. That callback copies the received payload into a 256-byte ring buffer, but the bounds logic is incorrect:
- It checks only
if (count < size)once before the copy loop - It does not verify that
count + rx_size <= size - It does not wrap
offsetduring the copy loop
As a result, if the ring buffer already contains 255 bytes and a new 2-byte message arrives, the callback writes:
- The first byte to
buf[255] - The second byte to
buf[256]
This is an out-of-bounds write.
The bug is not limited to the minimal 2-byte case. A larger second message increases the overwrite extent further because the loop continues writing past the end of the 256-byte receive buffer.
In addition, the read path in _read() also contains a wrap bug: it uses if (offset > rbsize) instead of if (offset >= rbsize). Once the ring-buffer state becomes invalid, this can also cause an out-of-bounds read on subsequent reads.
This issue is reachable in the current BSP integration. The input channel is concrete:
- The BSP is configured with
LINUX_RPROC_MASTER - CM4 initializes OpenAMP as
RPMSG_REMOTE - The virtual UART endpoint name is
rpmsg-tty-channel - The repository already includes
tools/rt-thread-shell.py, which writes to/dev/ttyRPMSG0
Therefore, an attacker who can control the OpenAMP peer, or who can send controlled input through the CA7/Linux side into /dev/ttyRPMSG0 or the corresponding rpmsg endpoint, can trigger this bug.
Fix Suggestion
A safe fix should address both the RX callback and the read path.
Suggested changes:
- In
VIRT_UART0_RxCpltCallback(), compute available space before copying:available = size - count- If
available == 0, drop the message or return an error
- Clamp
rx_sizeto the available space before entering the loop - Wrap
offseton each iteration, not only once before the loop - Ensure
device->serial.rbuf_countnever exceedsdevice->serial.rbuf_size - In
_read(), change the wrap condition fromif (offset > rbsize)toif (offset >= rbsize) - Prefer using a common ring-buffer helper instead of open-coded wrap logic
Pseudo-fix direction:
available = size - count;
rx_size = MIN(rx_size, available);
for (i = 0; i < rx_size; i++)
{
if (offset >= size)
offset = 0;
buf[offset++] = huart->pRxBuffPtr[i];
count++;
}
Exploitation Idea
Precondition: the attacker can control the OpenAMP peer, i.e. the CA7/Linux side can send data to /dev/ttyRPMSG0 or the corresponding rpmsg endpoint.
Minimal PoC idea:
- Send 255 bytes from the Linux side to make the CM4-side receive ring buffer nearly full.
- Send one more message with length 2.
- The second message triggers the out-of-bounds write in
VIRT_UART0_RxCpltCallback().
High-level example from the Linux side:
- Open
/dev/ttyRPMSG0 - Write 255 controlled bytes
- Then write 2 more controlled bytes
A simple proof-of-concept can be implemented with a short userspace program or script that performs two writes in sequence.
For a more stable reproduction:
- Make sure the CM4 side is not draining the
openampreceive buffer too quickly - For example, avoid using
openampas the active console during reproduction, or pause the consumer if applicable
Observation ideas:
- Monitor for CM4 fault / crash / unexpected behavior
- Inspect adjacent memory corruption effects after the second write
- After corrupting the ring state, trigger reads from the
openampdevice to exercise the buggy_read()wrap logic and observe potential OOB read behavior
Other additional context
No response
- Lenguaje dominante
- C
- Estrellas
- 12.3k
- Forks
- 5.5k
- Merge medio
- 4 d 12 h
- PR fusionados (30 d)
- 32
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de RT-Thread/rt-thread
-
[bsp][stm32][bluepill] README「快速上手」缺少重新生成 MDK 工程这一步,按文档操作无法编译通过Posiblemente ocupada @moment-NEW la tomó hace 1 día. Abiertoin progress
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
RT-Thread/rt-thread#11818 · 4 comentarios · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
BSP BSP: Loongson bug RT-Smart
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
RT-Thread/rt-thread#11717 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Arch: RISC-V BSP BSP: HPMicro bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
RT-Thread/rt-thread#11687 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
RT-Thread/rt-thread#11472 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
[Bug] Heap Buffer Overflow in FinSH `msh_auto_complete_path` via Oversized InputPosiblemente ocupada @Acen28 la tomó hace 8 días. AbiertoArch: ARM/AArch64 BSP BSP: STM32 bug Component component: finsh in progress
RT-Thread/rt-thread#11839 · 3 comentarios · 1 asignado ·
Los mantenedores suelen responder en 1 día
Todos los issues de RT-Thread/rt-thread
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
containers/bubblewrap#813 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
tree-sitter/tree-sitter#6005 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
facebookincubator/muse-gadget-sdk#47 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
kubernetes-sigs/security-profiles-operator#3537 ·
Los mantenedores suelen responder en 1 día