CVE-2024-2212 Overview
CVE-2024-2212 affects Eclipse ThreadX versions before 6.4.0. The xQueueCreate() and xQueueCreateSet() functions in the FreeRTOS compatibility API omit parameter validation. Missing checks allow integer wraparound during size calculations. The wraparound leads to under-allocation of heap buffers and subsequent heap buffer overflows during queue operations.
The flaw resides in utility/rtos_compatibility_layers/FreeRTOS/tx_freertos.c. Applications built on ThreadX that use the FreeRTOS compatibility shim to create queues are directly exposed. The vulnerability maps to [CWE-122] Heap-based Buffer Overflow and [CWE-190] Integer Overflow or Wraparound.
Critical Impact
A local attacker who controls queue creation parameters can trigger heap corruption in embedded firmware, leading to code execution or denial of service on affected devices.
Affected Products
- Eclipse ThreadX versions prior to 6.4.0
- Firmware using the ThreadX FreeRTOS compatibility layer (tx_freertos.c)
- Embedded and IoT products embedding vulnerable ThreadX builds
Discovery Timeline
- 2024-03-26 - CVE-2024-2212 published to NVD
- 2024-05-28 - Public discussion on Openwall OSS-Security mailing list
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-2212
Vulnerability Analysis
Eclipse ThreadX ships a FreeRTOS compatibility layer that translates FreeRTOS API calls into native ThreadX primitives. The affected functions, xQueueCreate() and xQueueCreateSet(), accept queue length and item size arguments from the caller. Both functions multiply these values to compute the total buffer size for the queue storage area.
The implementation performs no bounds checks on the caller-supplied parameters. When the product of queue length and item size exceeds the range of the integer type used in the calculation, the result wraps around to a small value. The allocator then reserves a buffer smaller than the queue actually requires.
Subsequent queue send operations write item-sized elements into this under-allocated buffer. Adjacent heap metadata and neighboring allocations are overwritten. Attackers who influence these inputs can corrupt heap structures used by the RTOS kernel and application code.
Root Cause
The root cause is missing parameter validation combined with unchecked arithmetic on 32-bit size values. Neither xQueueCreate() nor xQueueCreateSet() verifies that uxQueueLength * uxItemSize fits within the target integer type before passing the result to the memory allocator. This omission produces the integer wraparound described in [CWE-190], which then feeds the heap overflow classified as [CWE-122].
Attack Vector
Exploitation requires local access and user interaction, consistent with an attacker running code on the same device or supplying crafted input consumed by an application that calls the affected queue APIs. On embedded systems this often means a lower-privileged task, an untrusted firmware component, or a network-facing service that forwards user-controlled sizing values into queue creation. Successful exploitation compromises confidentiality, integrity, and availability of the RTOS.
No public proof-of-concept is currently listed for CVE-2024-2212. For technical detail, refer to the GitHub Security Advisory GHSA-v9jj-7qjg-h6g6 and the Full Disclosure mailing list post.
Detection Methods for CVE-2024-2212
Indicators of Compromise
- Unexpected task crashes or hard faults occurring shortly after queue creation calls in ThreadX firmware
- Heap corruption diagnostics or memory pool integrity failures reported by ThreadX at runtime
- Firmware images that statically link tx_freertos.c from ThreadX releases earlier than 6.4.0
Detection Strategies
- Perform a Software Bill of Materials (SBOM) review to identify all products using Eclipse ThreadX below 6.4.0.
- Scan firmware binaries for symbols xQueueCreate and xQueueCreateSet originating from the ThreadX compatibility layer.
- Audit application source code for calls to xQueueCreate() and xQueueCreateSet() that pass non-constant length or item-size parameters.
Monitoring Recommendations
- Enable ThreadX memory pool integrity checks and log allocation failures from device fleets to central telemetry.
- Track firmware versions across deployed embedded devices and alert when unpatched ThreadX builds appear.
- Monitor vendor advisories from device manufacturers that integrate ThreadX for downstream patch releases.
How to Mitigate CVE-2024-2212
Immediate Actions Required
- Upgrade Eclipse ThreadX to version 6.4.0 or later in all affected firmware builds.
- Rebuild and redeploy embedded firmware that statically links the ThreadX FreeRTOS compatibility layer.
- Inventory devices running vulnerable ThreadX versions and prioritize patching for network-exposed systems.
Patch Information
Eclipse ThreadX 6.4.0 adds parameter validation to xQueueCreate() and xQueueCreateSet() that rejects sizes causing integer wraparound. Fix details are published in the Eclipse ThreadX Security Advisory GHSA-v9jj-7qjg-h6g6. Downstream vendors should incorporate the upstream fix and reissue firmware to affected customers.
Workarounds
- Wrap calls to xQueueCreate() and xQueueCreateSet() with explicit checks that validate uxQueueLength * uxItemSize against SIZE_MAX before invocation.
- Constrain the FreeRTOS compatibility API to callers that pass compile-time constants where possible, eliminating attacker-controlled sizing.
- Restrict local access to devices running vulnerable firmware until patched builds are deployed.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
