Threadx
CVE-2026-0648
HIGH
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessExhaust counter pool via repeated CreateCounter calls
-
ExploitInvalid error code 12U cast to pointer
-
ExecutionWrite to arbitrary kernel memory
-
ImpactEscalate privileges and compromise system
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2021 - Vulnerable and Outdated Components
ASVS 5.0
V16 - Security Logging and Error Handling Incorrect check of return value
|
| Exploitation Conditions | Local access required; user-level privileges needed; ThreadX OSEK compatibility layer must be enabled; repeated CreateCounter() invocations to deplete osek_get_counter() pool; runs on systems with vulnerable tx_osek.c |
| Impact | CVSS 7.8 (HIGH). Attack vector: Local. Complexity: High. Privileges required: Low. User interaction: None. Exploitation no authentication required. |
| Exploit ScenarioDerived | An attacker without authentication could exploit this vulnerability to compromise the affected system. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Mar 12, 2026
Memory corruption in ThreadX RTOS CreateCounter() function allows local attackers with user privileges to trigger hard faults or corrupt kernel memory by exhausting the counter pool, which causes an unchecked error code to be cast as a wild pointer. The vulnerability stems from incorrect error validation logic that fails to detect counter allocation failures, enabling subsequent writes to arbitrary memory addresses. No patch is currently available.
Earlier versions of this analysis (1)
The vulnerability stems from an incorrect error-checking logic in the CreateCounter() function (in threadx/utility/rtos_compatibility_layers/OSEK/tx_osek.c) when handling the return value of osek_get_counter(). [CVSS 7.8 HIGH]
RemediationAI
Monitor vendor advisories for a patch.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability stems from an incorrect error-checking logic in the CreateCounter() function (in threadx/utility/rtos_compatibility_layers/OSEK/tx_osek.c) when handling the return value of osek_get_counter(). Specifically, the current code checks if cntr_id equals 0u to determine failure, but @osek_get_counter() actually returns E_OS_SYS_STACK (defined as 12U) when it fails. This mismatch causes the error branch to never execute even when the counter pool is exhausted.
As a result, when the c
Know when Threadx gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
DescriptionCVE.org
The vulnerability stems from an incorrect error-checking logic in the CreateCounter() function (in threadx/utility/rtos_compatibility_layers/OSEK/tx_osek.c) when handling the return value of osek_get_counter(). Specifically, the current code checks if cntr_id equals 0u to determine failure, but @osek_get_counter() actually returns E_OS_SYS_STACK (defined as 12U) when it fails. This mismatch causes the error branch to never execute even when the counter pool is exhausted.
As a result, when the counter pool is depleted, the code proceeds to cast the error code (12U) to a pointer (OSEK_COUNTER *), creating a wild pointer. Subsequent writes to members of this pointer lead to writes to illegal memory addresses (e.g., 0x0000000C), which can trigger immediate HardFaults or silent memory corruption.
This vulnerability poses significant risks, including potential denial-of-service attacks (via repeated calls to exhaust the counter pool) and unauthorized memory access.
Executive ViewAI
CVE-2026-0648 is a high-severity vulnerability affecting ThreadX RTOS systems that could allow attackers to cause application instability or denial of service through improper error handling in counter operations. Organizations running ThreadX-based embedded systems or industrial control devices are at risk, and the absence of available patches requires immediate risk assessment and mitigation planning.
Implement network segmentation to isolate ThreadX systems from untrusted networks; disable OSEK counter API functionality if not required for operations; deploy intrusion detection signatures targeting malformed counter requests; implement input validation at application layer; increase monitoring and alerting on CreateCounter() failures; restrict administrative access to counter configuration; consider temporary replacement with patched alternative RTOS if available and operationally feasible.
Threat Intelligence Overview
NVD
CVE.org
EPSS
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Affected Products (CPE)CVE.org
In Eclipse ThreadX before 6.4.0, xQueueCreate() and xQueueCreateSet() functions from the FreeRTOS compatibility API (uti
Eclipse ThreadX releases prior to 6.4.3 contain an incomplete pointer-validation flaw that lets a module-level caller cr
Eclipse ThreadX versions before 6.4.3 fail to enforce the configured maximum thread priority in certain thread-creation
Privilege escalation in Eclipse ThreadX allows an unprivileged, memory-protected ThreadX module to break out of its MPU
Secure memory disclosure in Eclipse ThreadX occurs because multiple TrustZone-M non-secure callable (NSC) entry function
In Eclipse ThreadX before version 6.4.0, the _Mtxinit() function in the Xtensa port was missing an array size check caus
Insufficient validation of syscall parameters in Eclipse ThreadX before 6.4.3, when the memory-protection feature is ena
Exploit-DB