This blog post discusses two newly discovered CVEs affecting Eclipse ThreadX before version 6.4.0: CVE-2024-2214 and CVE-2024-2212. Discovered by Humanativa Group, these vulnerabilities involve low-level memory exploits, including buffer overflows and integer wraparounds. Eclipse ThreadX is an open-source real-time operating system for embedded devices, formerly known as Azure RTOS. The blog emphasizes the importance of properly understanding and communicating the scope of vulnerabilities in popular software. Tools like ObjectSecurity’s BinLens\u2122<\/a> (formerly ObjectSecurity OT.AI Platform) can help detect and remediate such vulnerabilities efficiently.<\/strong><\/p>\n Two new CVEs (CVE-2024-2214, CVE-2024-2212) affecting Eclipse ThreadX at versions before 6.4.0 were recently discovered by Humanativa Group on May 26th, 2024. You can find Humanativa\u2019s blog post about the disclosure here<\/a>. Furthermore, GitHub user 0xdea documents the findings here<\/a>. These vulnerabilities both involve low-level memory exploits (buffer overflows and integer wrap arounds).<\/p>\n When Microsoft transferred ownership of Azure RTOS to the Eclipse foundation, the project was rebranded as Eclipse ThreadX. Eclipse ThreadX is an open-source real time operating system (RTOS) for embedded devices. You can view the GitHub repository for Eclipse ThreadX here<\/a>. Eclipse ThreadX is a widely adopted dependency used in many embedded systems and IoT devices. Vulnerabilities found in Eclipse ThreadX are positioned to cause a high degree of damage, should they go unaddressed.<\/p>\n I felt that the existing 3rd-party articles documenting these CVEs insufficiently describe their details, at least those details that I am interested in. Most notably, I could not find information regarding what devices are affected by these CVEs. With this context, this blog post seeks to deep dive into these CVEs, figuring out how they work and what embedded\/IoT devices they affect.<\/p>\n<\/div><\/div><\/div><\/div><\/div> This CVE has been published to the NVD here<\/a>. The NVD describes this CVE as:<\/p>\n In Eclipse ThreadX before version 6.4.0, the _Mtxinit() function in the Xtensa port was missing an array size check causing a memory overwrite. The affected file was ports\/xtensa\/xcc\/src\/tx_clib_lock.c.<\/em><\/p>\n<\/blockquote>\n As I already mentioned, this vulnerability affects Eclipse ThreadX versions before 6.4.0. You can view the commit which fixes the vulnerability here<\/a>. This commit is included in version 6.4.0 of Eclipse ThreadX, resolving the vulnerability.<\/p>\n When reading this CVE\u2019s description, I had a few questions. What is the Xtensa is a type of microprocessor developed by Tensilica Inc. You can read about them here<\/a>. Eclipse ThreadX has several ports. These ports are directories which include architecture and compiler specific source code files. This is illustrated in the source code directory breakdown below:<\/p>\n<\/div> The source code in these ports is only compiled into the final build of Eclipse ThreadX if the build is targeting the corresponding architecture and compiler. Because CVE-2024-2214 is found in As its name suggests, Eclipse ThreadX supports multithreading. When used as a dependency, it allows embedded systems to spawn multiple threads of processing at once. When two threads attempt to access a shared resource simultaneously, undefined behavior can occur, causing program crashes and other issues. To prevent this, mutexes (mutually exclusive flags) are used. Mutexes prevent multiple threads from accessing a shared resource at once. Eclipse ThreadX allows developers to create mutexs for this purpose.<\/p>\n The When called, Whenever Funnily enough, the developer who wrote this code made a note of this issue, labelling it The fix for this CVE was rather trivial, as is shown in the commit mentioned earlier:<\/p>\n<\/div> After this investigation, I summarized what devices this CVE affects in the following statement:<\/p>\n CVE-2024-2214 only affects embedded devices that are running Eclipse ThreadX before version 6.4.0, have Xtensa processors, and create many mutexes simultaneously.<\/em><\/p>\n<\/blockquote>\n<\/div><\/div><\/div><\/div><\/div> The second CVE has been published to the NVD here<\/a>. The NVD describes this CVE as:<\/p>\n In Eclipse ThreadX before 6.4.0, xQueueCreate() and xQueueCreateSet() functions from the FreeRTOS compatibility API (utility\/rtos_compatibility_layers\/FreeRTOS\/tx_freertos.c) were missing parameter checks. This could lead to integer wraparound, under-allocations and heap buffer overflows.<\/em><\/p>\n<\/blockquote>\n The commit addressing this vulnerability (which is included in version 6.4.0 of Eclipse ThreadX) can be found here<\/a>.<\/p>\n Just like before, when reading the description of this CVE, I had a couple questions. What is the FreeRTOS compatibility API? What are the To help ease migration to ThreadX RTOS, Eclipse ThreadX supports adaptation layers for various legacy RTOS APIs, one of which is FreeRTOS. Programs which depend upon the FreeRTOS API may instead use Eclipse ThreadX under the hood by interacting with this FreeRTOS compatibility API.<\/p>\n The FreeRTOS compatibility API implements various functions defined by the original FreeRTOS specification. Two of these functions are The way Let\u2019s look at the source code for On line 1536, The source code for Just like before, the fix was rather trivial. The developer instead returns early from the function if the queue length is large enough to cause an integer wraparound.<\/p>\n<\/div> Because CVE-2024-2212 only affects embedded devices that are running Eclipse ThreadX before version 6.4.0 and are running applications which use the FreeRTOS compatibility layer API to create queues.<\/em><\/p>\n<\/blockquote>\n<\/div><\/div><\/div><\/div><\/div> When news organizations write articles about CVEs, they sometimes under or overrepresent the number of devices that are affected. In this case, the devices affected represent only a small percentage of all devices running Eclipse ThreadX. However, in the future this could be reversed: the number of devices affected by a vulnerability could be greater than what popular reporting indicates. For this reason, we urge individuals to seek out reliable and detailed sources of information while researching a CVE that might affect them.<\/p>\n We place a lot of trust in open-source software, and open-source software is not immune to obvious, unpublished vulnerabilities. Detecting all these unpublished vulnerabilities manually can be quite difficult if not impossible. ObjectSecurity’s BinLens\u2122<\/a> (formerly ObjectSecurity OT.AI Platform) detects memory vulnerabilities like those written about here, before they are published to the National Vulnerability Database as CVEs. With ObjectSecurity’s BinLens\u2122<\/a> (formerly ObjectSecurity OT.AI Platform), you can detect binary weaknesses and vulnerabilities in a reliable, fast, automated way.<\/p>\n<\/div>CVE-2024-2214<\/h2>\n<\/div>
\n
_Mtxinit()<\/code> function? What is an Xtensa port? What array check was missed to cause the memory overwrite?<\/p>\n![](\"https:\/\/i0.wp.com\/objectsecurity.com\/wp-content\/uploads\/2024\/06\/threadx_dirs.png?resize=624%2C318&ssl=1\" "\\"threadx_dirs\\"")
<\/span><\/div>Eclipse ThreadX Source Code Directory Breakdown<\/em><\/h6>\n<\/div>
ports\/xtensa\/xcc\/src\/tx_clib_lock.c<\/code>, it will only be compiled into builds targeting Xtensa processors.<\/p>\n_Mtxinit()<\/code> function is called whenever a mutex is initiated (hence the name) by the Xtensa C library or newlib C library that is distributed with Xtensa Tools. Let\u2019s look at _Mtxinit()<\/code>\u2019s source code:<\/p>\n<\/div>![](\"https:\/\/i0.wp.com\/objectsecurity.com\/wp-content\/uploads\/2024\/06\/src1.png?resize=624%2C636&ssl=1\" "\\"src1\\"")
<\/span><\/div>_Mtxinit() Source Code<\/h6>\n<\/div>
_Mtxinit()<\/code> initializes a new mutex using the tx_mutex_create<\/code> function defined by the ThreadX API. This mutex is stored in the xclib_locks<\/code> global variable. xclib_locks<\/code> is an array of size XT_NUM_CLIB_LOCKS<\/code>, meaning it can only store a finite number of mutexes at once.<\/p>\n_Mtxinit()<\/code> is called, it increments the counter called lcnt<\/code>. lcnt<\/code> can be incremented to a value higher than the size of xclib_locks<\/code>. When this happens, there is a memory overwrite, causing the CVE. Memory overwrites can cause undefined behavior and can be manipulated by savvy attackers to do damage. This particular CVE can be exploited if an attacker is able to initialize a large number of mutexes simultaneously, if such a thing is possible in upstream code.<\/p>\n\/* Fatal error *\/<\/code>, as you can see in the source code. The developer even included an if statement to check for the condition where lcnt exceeds the size of xclib_locks<\/code>, although they didn\u2019t programmatically address the issue in any way.<\/p>\n![](\"https:\/\/i0.wp.com\/objectsecurity.com\/wp-content\/uploads\/2024\/06\/src2.png?resize=624%2C139&ssl=1\" "\\"src2\\"")
<\/span><\/div>_Mtxinit() Source Code – Fixed<\/h6>\n<\/div>
\n
CVE-2024-2212<\/h2>\n<\/div>
\n
xQueueCreate()<\/code> and xQueueCreateSet()<\/code> functions? What parameter checks were missing?<\/p>\nxQueueCreate()<\/code> and xQueueCreateSet()<\/code>. FreeRTOS allows for the creation of tasks and queues. Tasks are similar to threads, and queues enable messages to be passed between tasks. Under the hood, ThreadX uses its own internal data structures (i.e., threads, semaphores, etc.) to support the FreeRTOS API functions such as xQueueCreate()<\/code> and xQueueCreateSet()<\/code>. You can read more about FreeRTOS queues here<\/a>.<\/p>\nxQueueCreate()<\/code> and xQueueCreateSet()<\/code> were implemented in the ThreadX FreeRTOS adaptation layer allows for integer wraparounds. An integer wraparound occurs when an integer value is incremented to a value that is too large to store in the associated bit representation. When this occurs, increasing the value will cause a large number to become a very small number.<\/p>\nxQueueCreate()<\/code>.<\/p>\n<\/div>![](\"https:\/\/i0.wp.com\/objectsecurity.com\/wp-content\/uploads\/2024\/06\/src3.png?resize=624%2C404&ssl=1\" "\\"src3\\"")
<\/span><\/div>xQueueCreate() Source Code<\/h6>\n<\/div>
mem_size<\/code> amount of memory is allocated to hold the queue being created. On line 1534, we see that mem_size<\/code> is defined as uxQueueLength*(uxItemSize)<\/code> (the length of the queue multiplied by the size of a single item in the queue). Because these arguments are controlled by the caller of the function, the caller can opt to set both values to be very large. When the values are made too large, this multiplication causes an integer wraparound. This integer wraparound results in a very small value for mem_size<\/code>, a value that is much smaller than that which is needed to hold the queue being created.<\/p>\nxQueueCreateSet()<\/code> has this same issue, so I am not including its source code in this blog post.<\/p>\n![](\"https:\/\/i0.wp.com\/objectsecurity.com\/wp-content\/uploads\/2024\/06\/src4.png?resize=624%2C178&ssl=1\" "\\"src4\\"")
<\/span><\/div>xQueueCreate() Source Code – Fixed<\/h6>\n<\/div>
xCreateQueue()<\/code> and xCreateQueueSet()<\/code> are part of an external API to be used by upstream code, the values of those parameters passed to the vulnerable functions depend on the upstream code. We can summarize what devices are affected by this CVE as such:<\/p>\n\n
Conclusion<\/h2>\n<\/div>