Embedded developers often say that memory protection is complicated. We don’t agree. Recently, we organized a workshop demonstrating advantages of memory protection usage in microcontroller applications. Part of the workshop consisted of integrating CMRX into vulnerable firmware. This integration consisted of 35 lines of code.
The whole point of workshop was to guide attendees through the process of exploitation of a vulnerability in embedded system. We used an obviously vulnerable driver and then explored possibilities of its exploitation. Before the workshop turned into its second half, the vulnerable driver was successfully exploited and attendees got full control over the simulated device. If this was a real device and situation wasn’t a workshop rather real attack, this would be a major security incident. We managed not only to divert code execution to another place in original firmware. We managed to deliver custom piece of code which got actually executed. Situation, where attacker can deliver and execute their own code is severe accident, because it breaks both security and safety assumptions.
This situation is more common than you may think. If your device is connected, then remote users already write your device’s RAM. Whether it is network packet, radio frame or serial data received by your device, it was put together remotely. You can do nothing about it, accepting remotely-composed data in your RAM is part of the game. If this data remains just a harmless information or it gets turned into an attack is decided by overall security architecture. Typical IoT firmware running on microcontroller is fragile. The only barrier preventing data being weaponized as attack payload is “lack” of security vulnerabilities. Put one in and the barrier is gone. It is just a matter of will if it gets discovered and exploited.
Memory protection adds additional barrier as it introduces rules on where code can write, where it can read from and what can be executed. CMRX was used to demonstrate this as it was quick to integrate and we could demonstrate how memory protection guards against vulnerabilities without changing single line in vulnerable driver. You can observe this yourself! We compiled the vulnerable driver, the CMRX integration and exploits into demonstration repository.
What is in this repository?
Subdirectory vulnerable contains an STM32 project based on CubeMX with obviously vulnerable serial port driver. This driver doesn’t perform bounds checking on received serial data and one can overwrite its stack-allocated buffer. If you think that nobody would commit such obviously-vulnerable code into production, then we’d like to remind you that CVE 2026-6687 is exactly the same class of vulnerability.
Subdirectory cmrx_vulnerable contains very same project with CMRX RTOS integrated. None of original driver files were altered. Driver was integrated into CMRX ecosystem to run as userspace component.
To confirm how many lines we actually changed, you can see it yourself! Run:
diff -Naur vulnerable cmrx_vulnerable
Both projects contain Renode simulator scripts so you can run them without having target HW. Renode exposes GDB port, so you can see effects of attack in real-time.
There are three binary files, which can be sent to simulated environment:
normal-input.bin is payload that is within expected protocol the driver implements. It will cause normal response and won’t break anything.exploit-vulnerable.bin is payload which will cause a vulnerability in vulnerable firmware to be exploited and cause remote code execution (RCE).exploit-cmrx.bin is same payload as before, updated to affect driver integrated in CMRX. Due to memory protection rules in CMRX, it is not effective and won’t cause RCE.If you follow instructions in README, you can build the firmware yourself, inject the payload and observe what happens. You’ll see that if exploit is applied to CMRX-protected firmware, hardware will catch it and raise an error.
This is the degree of added security CMRX can deliver to your project. Contact us if you are interested in hearing more.