[Bug] OOB write in OpenAMP virtual UART RX ring buffer on stm32mp157a-st-ev1
Mantenedores costumam responder em até 1 dia
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 48/100
- Tipo de issue
- Bug
- Clareza
- Razoavelmente clara
- Status de atividade
- Pouca atividade
- Stack de tecnologia
- c
- Domínio
- embedded-iot, operating-systems
Direção de pesquisa
Comece em drv_openamp.c do BSP do STM32MP157A-ST-EV1, em VIRT_UART0_RxCpltCallback() e _read(), e depois analise como VIRT_UART_read_cb() passa os dados rpmsg para o callback de RX. Reproduza o problema com escritas controladas em /dev/ttyRPMSG0, incluindo uma escrita de 255 bytes seguida por uma escrita de 2 bytes. Considera-se concluído quando o anel RX não puder escrever além do próprio buffer, a condição de wrap da leitura for segura e a reprodução não causar mais corrupção nem um fault.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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
- Linguagem predominante
- C
- Estrelas
- 12.3k
- Forks
- 5.5k
- Merge médio
- 4d 12h
- PRs com merge (30d)
- 32
Preparar o ambiente
Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.
- Sem Dockerfile nem arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de RT-Thread/rt-thread
-
bug Component component: net
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 90/100
RT-Thread/rt-thread#11852 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
[bsp][stm32][bluepill] README「快速上手」缺少重新生成 MDK 工程这一步,按文档操作无法编译通过Talvez já em andamento @moment-NEW assumiu há 2 dias. Abertain progress
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
RT-Thread/rt-thread#11818 · 4 comentários · 1 responsável ·
Mantenedores costumam responder em até 1 dia
-
BSP BSP: Loongson bug RT-Smart
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
RT-Thread/rt-thread#11717 · 2 comentários ·
Mantenedores costumam responder em até 1 dia
-
Arch: RISC-V BSP BSP: HPMicro bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
RT-Thread/rt-thread#11687 · 3 comentários ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
RT-Thread/rt-thread#11472 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
Todas as issues de RT-Thread/rt-thread
Issues semelhantes
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
EchoTools/nevr-runtime#117 · 2 comentários ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 67/100
DarkFlippers/qUnleashed#240 ·
Mantenedores costumam responder em até 1 dia
-
enhancement
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 84/100
AFLplusplus/AFLplusplus#2899 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
HarbourMasters/Shipwright#7320 ·
Mantenedores costumam responder em até 1 dia