CVE-2026-77237

This CVE exposes a fundamental mismatch between FreeRTOS's queue-set mechanism and the privilege model that MPU-enabled ports enforce. When configUSE_QUEUE_SETS=1 is enabled, an unprivileged task can call xQueueAddToSet() on a queue allocated in a privileged memory region and effectively read into protected kernel memory — the MPU boundary that should isolate that memory gets bypassed entirely. The vulnerability isn't a null pointer or buffer overflow; it's a missing cross-subsystem validation where the queue-set API was never integrated with MPU port privilege checks. The CVSS 6.5 undersells the significance. In safety-critical deployments — industrial control, medical devices, automotive systems — that run MPU-enabled FreeRTOS, queue sets often synchronize tasks across privilege boundaries: sensor aggregation tasks, communications handlers, safety monitors. If an unprivileged task can leak or poison those queues, the operational impact far exceeds what the exploitability score suggests. This is also the latest instance of a recurring pattern. FreeRTOS-Kernel has a documented history of MPU boundary violations in IPC primitives — queue operations across task boundaries that assume flat memory semantics and skip privilege validation. The queue-set code predates MPU port trust boundaries and was never re-examined when those boundaries arrived. It just kept compiling. The critical question about the 11.3.1 fix: does it implement precise privilege validation for queue memory regions, or does it simply disable queue-set operations for unprivileged tasks entirely? The latter creates a new failure mode — tasks that legitimately need cross-privilege queue access silently break, potentially causing watchdog timeouts or system deadlock in production. That's a reliability blast radius the CVE doesn't capture. For defenders: audit your FreeRTOS configuration for configUSE_QUEUE_SETS=1. If you're on an MPU-enabled port, verify what the 11.3.1 update actually does in practice — precise validation or blanket denial. More importantly, treat this as evidence that the queue-set API surface deserves systematic audit. Other xQueue* functions operating across task boundaries (xQueueSendToBackFromISR, xQueueReceive) have had analogous gaps in the past. This CVE may be a one-off patch or the beginning of a necessary systematic review — monitor how FreeRTOS maintainers respond.

Reviewed through automated stages and approved by a human before publication.