Today, we’re sharing details of a remote code execution (RCE) vulnerability discovered in the Arduino Portenta firmware running on the STM32H747AIIX Cortex‑M7 core. Metalware, an automated firmware fuzzing platform, was instrumental in uncovering this flaw. In this post, we provide an in‑depth overview of the vulnerability and the potential risks it poses in various industries.

Overview of the Arduino Portenta and Its Industrial Impact

The Arduino Portenta series, built around high‑performance microcontrollers such as the STM32H747AIIX (Cortex‑M7), has become a popular choice for advanced prototyping and industrial applications. Its capabilities make it a cornerstone in areas including:

• Industrial Automation & Control: For real‑time processing, sensor interfacing, and data aggregation.
• Edge Computing & IoT: Enabling complex computations at the edge while maintaining low power consumption.
• Robotics & Drones: Providing high‑performance processing in systems that demand both speed and reliability.
• Medical & Safety‑Critical Devices: Where integrity and security are paramount.

A vulnerability in such a widely used platform can have far‑reaching consequences. In safety‑critical or industrial environments, an RCE flaw could lead to unauthorized control of devices, data breaches, or even physical damage.

How the Vulnerability Works

Our analysis of the Portenta firmware revealed a multi‑stage vulnerability that can ultimately lead to remote code execution. The vulnerability arises from the handling of data received over the SPI interface and involves a chain of operations that culminate in a stack corruption. Below is a high‑level summary of the discovery:

1. Receiving a payload via attacker-controlled SPI
   • HAL_SPI_IRQHandler reads packet data from the SPI peripheral’s data RX registers into RAM.
   • The first two bytes of the packet—intended to represent the packet size—are written to specific memory locations.
2. Erroneous Data Copying:
   • HAL_SPI_TxRxCpltCallback is triggered upon completion of the SPI transfer.
   • This callback copies the packet data from RAM to a global buffer (RX_Buffer_userspace) via a memcpy(), inadvertently transferring the attacker‑controlled size field.
3. Vulnerable Data Handling:
   • The function dma_handle_data() retrieves the packet and its size from the user‑controlled buffer.
   • Through a series of function calls—dma_handle_data() → peripheral_invoke_callback() → fdcan1_handler() → fdcan_handler()—the data and its size are ultimately passed to another memcpy() call.
4. Stack Corruption Leading to RCE:
   • The final memcpy() overwrites a stack buffer corrupting the stack frame of fdcan_handler().
   • With control of the saved link return register, an attacker can manipulate the program counter during the function return, paving the way for remote code execution.

In essence, by manipulating the packet size field—an attacker can exploit the chain of memory copies to ultimately overwrite critical control data on the stack, leading to RCE.

Metalware Fuzzer