CVE-2026-77237 in FreeRTOS
Summary
by MITRE • 08/21/2026
Missing queue-set type validation in xQueueAddToSet() in the FreeRTOS-Kernel before 11.3.1 might allow an unprivileged task on MPU-enabled ports with configUSE_QUEUE_SETS=1 to read privileged kernel memory. To remediate this issue, users should upgrade to version 11.3.1 or later.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in FreeRTOS-Kernel versions prior to 11.3.1 represents a critical failure in access control mechanisms within the operating system's kernel synchronization primitives. Specifically, the flaw resides in the xQueueAddToSet function, which is responsible for managing queue sets—a feature that allows multiple queues to be waited on simultaneously by a single task using the uxQueueWaitForMessage API. In configurations where Memory Protection Unit (MPU) support is enabled and configUSE_QUEUE_SETS is set to one, the kernel fails to perform adequate validation of the queue-set type before proceeding with memory operations. This oversight creates a pathway for privilege escalation or unauthorized data exfiltration by lower-privileged tasks that are otherwise restricted from accessing sensitive kernel structures due to MPU boundaries.
From a technical perspective, the root cause is classified under CWE-284 Improper Access Control and CWE-190 Integer Overflow or Wraparound if type validation failures lead to incorrect pointer arithmetic or memory mapping assumptions. The xQueueAddToSet function interacts with internal queue data structures that are typically protected by MPU regions designed to isolate kernel space from user task space. When the input parameters, particularly those defining the nature of the queues being added to a set, are not rigorously validated against expected types and permissions, the function may inadvertently reference or map memory addresses associated with privileged kernel objects into the address space accessible to an unprivileged task. This bypasses the hardware-enforced isolation that MPU is designed to provide, effectively nullifying one of FreeRTOS's primary security features for embedded systems requiring strict separation between application code and operating system internals.
The operational impact of this vulnerability is severe in environments where multiple tasks with varying privilege levels coexist within a single address space managed by an MPU. An attacker or malicious unprivileged task could exploit this flaw to read privileged kernel memory, potentially extracting cryptographic keys, session tokens, configuration data, or other sensitive information stored in the kernel heap or static variables. Furthermore, depending on how the invalid queue-set type is interpreted by subsequent kernel operations, there may be secondary risks involving stack corruption or denial of service if the malformed reference leads to illegal memory accesses that trigger hard faults. In safety-critical applications such as automotive control systems, medical devices, or industrial automation, this could lead to catastrophic failures where system integrity and confidentiality are compromised without triggering standard security alarms.
This vulnerability aligns with MITRE ATT&CK techniques related to Privilege Escalation via OS Exploitation and Collection of Application Data through Memory Access. It highlights the importance of rigorous input validation in kernel-level synchronization primitives, especially when hardware-assisted memory protection is relied upon for security enforcement. The absence of such checks undermines the trust model assumed by developers who configure MPU regions based on the expectation that certain code paths will strictly adhere to defined access boundaries.
To remediate this issue and restore secure operation, it is imperative to upgrade FreeRTOS-Kernel to version 11.3.1 or any later release where the xQueueAddToSet function has been patched with proper type validation logic. Developers should verify that their build configurations correctly enable MPU support if they are operating in multi-privileged task environments. Additionally, security audits of custom kernel modifications and third-party port implementations are recommended to ensure no similar gaps exist in other synchronization mechanisms like semaphores or mutexes. Regular updates to the RTOS core remain the most effective mitigation strategy against such low-level implementation flaws that can bypass hardware-enforced isolation boundaries.