Bypassing MPU-Based Protections in Commodity RTOS via Trampoline Functions

TLDR: Researchers at Black Hat 2023 demonstrated that many Real-Time Operating Systems (RTOS) rely on insecure "trampoline functions" to handle privilege transitions, creating a massive attack surface for privilege escalation. By exploiting missing legitimacy checks during these mode switches, an attacker can achieve arbitrary read/write access, effectively neutralizing MPU-based memory isolation. Security researchers should audit their target RTOS firmware for these patterns using the provided CodeQL scripts to identify similar vulnerabilities.

Embedded systems are everywhere, from medical devices to industrial controllers, and they almost universally run on an RTOS. For years, we have been told that the Memory Protection Unit (MPU) provides a necessary layer of security, partitioning memory regions to prevent a compromised task from touching kernel space or other tasks. However, the research presented by Minghao Lin at Black Hat 2023 proves that this hardware-backed security is often undermined by the very software designed to manage it. The core issue lies in how these systems handle the transition between unprivileged tasks and privileged kernel services.

The Trampoline Function Vulnerability

Most RTOS implementations use "trampoline functions" to bridge the gap between user mode and kernel mode. When an unprivileged task needs to perform a system call, it calls a wrapper function—the trampoline—which elevates privileges, executes the kernel code, and then drops privileges back to the user level. The vulnerability arises because many of these trampoline functions fail to properly validate the parameters passed from the unprivileged task before executing the requested kernel operation.

If the trampoline function does not verify that the pointers or data passed by the user task are legitimate, an attacker can pass arbitrary pointers to the kernel. This effectively turns the kernel into a confused deputy, performing read or write operations on behalf of the attacker in memory regions that should be protected. This is a classic Broken Access Control scenario, but applied to the low-level memory management of embedded devices.

Technical Mechanics of the Exploit

The research highlights two primary failure modes: missing legitimacy checks during mode switches and improper MPU configuration. In the case of missing checks, the trampoline function simply trusts the input. Consider a hypothetical vTaskGetInfo function that takes a pointer to a task structure. If the trampoline doesn't check if that pointer resides in user-accessible memory, an attacker can point it to a kernel-space structure.

// Simplified example of a vulnerable trampoline pattern
void MPU_vTaskGetInfo(TaskHandle_t xTask, TaskStatus_t *pxTaskStatus) {
    // Missing check: Is xTask in user memory?
    // Missing check: Is pxTaskStatus in user memory?
    vTaskGetInfo(xTask, pxTaskStatus); // Kernel function call
}

By passing a pointer to a TaskControlBlock (TCB) that resides in kernel memory, an attacker can force the kernel to overwrite critical data, such as task priority or even the function pointers used for task scheduling. Once you control the TCB, you control the execution flow of the system. The researchers demonstrated that this technique works across multiple commodity RTOS platforms, including FreeRTOS, ThreadX, Tizen, RT-Thread, and Arm Mbed.

Real-World Impact for Pentesters

For a pentester or bug bounty hunter, this research changes the game for embedded device assessments. Previously, if you saw an MPU in the datasheet, you might have assumed memory corruption was off the table. Now, you should focus your efforts on the system call interface. If you can identify the trampoline functions—usually prefixed with MPU_ or similar—you have a direct path to privilege escalation.

During an engagement, look for system calls that accept pointers as arguments. Use a debugger to trace these calls from the user task into the kernel. If you can pass a pointer that points to a memory region outside the current task's allocated stack or heap, you have found a potential entry point. The impact is total system compromise; once you can read and write arbitrary memory, you can dump firmware, extract cryptographic keys, or disable security features entirely.

Defensive Mitigations

Defenders and firmware developers must treat the system call boundary as a high-risk interface. The most effective mitigation is to implement strict validation for every pointer passed to a trampoline function. The kernel must verify that the memory range specified by the user task is entirely contained within the user-accessible region. Furthermore, replacing raw object pointers with object IDs—where the kernel maintains a lookup table—prevents attackers from crafting arbitrary memory addresses.

The research team worked closely with the Amazon team to patch these issues in FreeRTOS, demonstrating that these vulnerabilities are fixable with rigorous code audits. If you are developing for these platforms, ensure you are using the latest versions and, more importantly, audit your own custom system calls against these same patterns.

The era of trusting MPU-based isolation blindly is over. As we continue to push more intelligence to the edge, the complexity of these RTOS kernels will only increase, and with it, the likelihood of these subtle, high-impact bugs. Start by running the researchers' CodeQL analysis against your own codebase. You might be surprised at what you find lurking in your trampoline functions.