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:
- 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.
- 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 amemcpy()
, inadvertently transferring the attacker‑controlled size field.
- 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 anothermemcpy()
call.
- Stack Corruption Leading to RCE:
- The final
memcpy()
overwrites a stack buffer corrupting the stack frame offdcan_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
Our Metalware Firmware Fuzzer was key to uncovering this vulnerability. Here’s how:
- Automated Fuzzing at Scale:
Metalware continuously generates and injects a wide range of input sequences, including edge‑case and malformed data, into the firmware. This approach stresses the system beyond what conventional testing might cover.
- Precise Fault Detection:
By monitoring memory accesses and register states, Metalware was able to pinpoint where unexpected behavior occurred during the SPI data transfer and DMA handling processes.
- Real‑World Simulation:
Metalware’s simulation of real‑world operating conditions—including DMA operations and SPI transactions—allowed us to reproduce the vulnerability reliably, ensuring that our analysis was based on concrete, repeatable behavior.
Potential Impact
The implications of this vulnerability are far‑reaching:
- Remote Code Execution (RCE):
An attacker can gain full control over a device, potentially compromising the entire system. In industrial settings, this could lead to production halts, data breaches, or even dangerous malfunctions.
- Compromised Safety‑Critical Systems:
Devices used in medical, automotive, or aerospace applications rely on robust security. Exploiting such a vulnerability could result in incorrect or unsafe operation, endangering lives.
- Reputational and Financial Damage:
Beyond the technical risks, a vulnerability of this nature can result in significant recalls, legal liabilities, and long‑term damage to a company’s reputation.
Disclosure Timeline
January 3, 2025 - Metalware emails Arduino team
February 17, 2025 - Metalware requests an update, receives no response
March 10, 2025 - Metalware requests an update
March 11, 2025 - Arduino confirms they are working on a fix
March 14, 2025 - Arduino notifies Metalware that fix has been merged
April 3, 2025 - Advisory published