FreeRTOS-Kernel CVE-2026-77237

Two specific compile-time configuration conditions must both be present: (1) the target must use an MPU-enabled FreeRTOS port (i.e., the port variant that activates Memory Protection Unit enforcement, segregating unprivileged tasks from kernel memory), and (2) the kernel must be compiled with configUSE_QUEUE_SETS=1 in FreeRTOSConfig.h, enabling the queue set API including xQueueAddToSet(). Devices built without MPU support or with configUSE_QUEUE_SETS=0 (the typical default) are completely unaffected. Exploitation is further limited to local task execution: the attacker must have the ability to run code as an unprivileged FreeRTOS task on the target device, ruling out purely network-based exploitation. The CVSS vector confirms PR:L (low-privilege task) and AV:L (local), meaning an attacker with no existing code execution on the device cannot trigger this vulnerability remotely.

The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N, score 8.2) indicates local exploitation by a low-privileged task with no user interaction, yielding high confidentiality impact on both the vulnerable system and a subsequent (privileged) system context - here, the kernel memory space. However, the vendor-supplied AT:N rating warrants scrutiny: exploitation demonstrably requires two non-default preconditions (MPU-enabled port AND configUSE_QUEUE_SETS=1), suggesting AT:P (attack requirements present) may be more accurate, which would reduce real-world exploitability. No CISA KEV listing and no public POC exist, so exploitation remains theoretical. The information-disclosure-only impact (VI:N/VA:N) limits blast radius - this is a read primitive, not arbitrary code execution - though privileged kernel memory leakage could expose cryptographic keys, task credentials, or sensitive runtime state that enables follow-on attacks. The risk is real but scoped: devices not using MPU or queue sets are entirely unaffected, and FreeRTOS is predominantly deployed in resource-constrained embedded contexts where network-reachable threat actors first require physical or firmware-level access.

A firmware image running on an STM32 or similar Cortex-M device with the MPU enabled and configUSE_QUEUE_SETS=1 hosts both a privileged driver task and an unprivileged application task. The unprivileged task calls xQueueAddToSet() passing a handle to an incompatible object type; because the kernel performs no type check, it processes the object as a valid queue-set member and subsequently dereferences or exposes a pointer into privileged memory. The unprivileged task reads kernel-managed data - potentially including cryptographic material or configuration secrets - without triggering an MPU fault. No public exploit or proof-of-concept code is known at time of analysis.