Refine your search
9 vulnerabilities found for Eclipse ThreadX by Eclipse Foundation
CVE-2026-95107 (GCVE-0-2026-95107)
Vulnerability from cvelistv5
Published
2026-10-20 15:20
Modified
2026-10-20 17:05
Severity ?
VLAI Severity ?
EPSS score ?
CWE
Summary
A ThreadX module chooses `object_size` when it calls `txm_module_object_allocate`. The Module Manager adds its own 16-byte private header to that size and asked the object pool for the result **without checking the addition**. A size near the top of a `ULONG` wrapped, the pool served a block far smaller than the header, and the manager then wrote the header past the end of it and into the neighbouring byte-pool block.
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Eclipse Foundation | Eclipse ThreadX |
Version: 6.0.1 ≤ 6.5.1.202602a |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-95107",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-20T17:05:27.399674Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T17:05:35.811Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageName": "ThreadX",
"product": "Eclipse ThreadX",
"vendor": "Eclipse Foundation",
"versions": [
{
"lessThanOrEqual": "6.5.1.202602a",
"status": "affected",
"version": "6.0.1",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.5.2.202603"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "fdesbiens"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA ThreadX module chooses `object_size` when it calls `txm_module_object_allocate`. The Module Manager adds its own 16-byte private header to that size and asked the object pool for the result **without checking the addition**. A size near the top of a `ULONG` wrapped, the pool served a block far smaller than the header, and the manager then wrote the header past the end of it and into the neighbouring byte-pool block.\u003c/p\u003e"
}
],
"value": "A ThreadX module chooses `object_size` when it calls `txm_module_object_allocate`. The Module Manager adds its own 16-byte private header to that size and asked the object pool for the result **without checking the addition**. A size near the top of a `ULONG` wrapped, the pool served a block far smaller than the header, and the manager then wrote the header past the end of it and into the neighbouring byte-pool block."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 7,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-190",
"description": "CWE-190 Integer Overflow or Wraparound",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-680",
"description": "CWE-680 Integer Overflow to Buffer Overflow",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-787",
"description": "CWE-787 Out-of-bounds Write",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T15:20:15.011Z",
"orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"shortName": "eclipse"
},
"references": [
{
"url": "https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-63qc-jcr6-qw6r"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Module object allocation size overflow corrupts the manager object pool",
"x_generator": {
"engine": "Vulnogram 1.0.5"
}
}
},
"cveMetadata": {
"assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"assignerShortName": "eclipse",
"cveId": "CVE-2026-95107",
"datePublished": "2026-10-20T15:20:15.011Z",
"dateReserved": "2026-09-23T13:43:04.307Z",
"dateUpdated": "2026-10-20T17:05:35.811Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-94202 (GCVE-0-2026-94202)
Vulnerability from cvelistv5
Published
2026-10-20 15:19
Modified
2026-10-20 17:04
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-125 - Out-of-bounds Read
Summary
The Module Manager's block-pool create dispatcher proved that two `ALIGN_TYPE` words of the extra-parameter array a memory-protected module supplies lay inside the module's data, and then used indices 0 through 3 of that array.
One of the two unproved words is read by the dispatcher's own buffer check, which takes index 1 as the pool start and index 2 as the length to range-check it over. So the out-of-bounds read is performed by the validation code itself, before the kernel service is reached, and the size the caller's pool start is then validated against is a word the manager has not proved the module owns. The other unproved word is read when the service's argument list is built.
Vulnerable function: `_txm_module_manager_tx_block_pool_create_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`.
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Eclipse Foundation | Eclipse ThreadX |
Version: 6.0.1 ≤ 6.5.1.202602a |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-94202",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-20T17:04:43.658861Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T17:04:52.595Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageName": "ThreadX",
"product": "Eclipse ThreadX",
"vendor": "Eclipse Foundation",
"versions": [
{
"lessThanOrEqual": "6.5.1.202602a",
"status": "affected",
"version": "6.0.1",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.5.2.202603"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "fdesbiens"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe Module Manager\u0027s block-pool create dispatcher proved that two `ALIGN_TYPE` words of the extra-parameter array a memory-protected module supplies lay inside the module\u0027s data, and then used indices 0 through 3 of that array.\u003c/p\u003e\u003cp\u003eOne of the two unproved words is read by the dispatcher\u0027s own buffer check, which takes index 1 as the pool start and index 2 as the length to range-check it over. So the out-of-bounds read is performed by the validation code itself, before the kernel service is reached, and the size the caller\u0027s pool start is then validated against is a word the manager has not proved the module owns. The other unproved word is read when the service\u0027s argument list is built.\u003c/p\u003e\u003cp\u003eVulnerable function: `_txm_module_manager_tx_block_pool_create_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`.\u003c/p\u003e"
}
],
"value": "The Module Manager\u0027s block-pool create dispatcher proved that two `ALIGN_TYPE` words of the extra-parameter array a memory-protected module supplies lay inside the module\u0027s data, and then used indices 0 through 3 of that array.\n\n\n\nOne of the two unproved words is read by the dispatcher\u0027s own buffer check, which takes index 1 as the pool start and index 2 as the length to range-check it over. So the out-of-bounds read is performed by the validation code itself, before the kernel service is reached, and the size the caller\u0027s pool start is then validated against is a word the manager has not proved the module owns. The other unproved word is read when the service\u0027s argument list is built.\n\n\n\nVulnerable function: `_txm_module_manager_tx_block_pool_create_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 4.8,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "CWE-125 Out-of-bounds Read",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T15:19:43.014Z",
"orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"shortName": "eclipse"
},
"references": [
{
"url": "https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-5w57-xhwq-v7wq"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Module block-pool create validates two of the four parameter words it reads",
"x_generator": {
"engine": "Vulnogram 1.0.5"
}
}
},
"cveMetadata": {
"assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"assignerShortName": "eclipse",
"cveId": "CVE-2026-94202",
"datePublished": "2026-10-20T15:19:43.014Z",
"dateReserved": "2026-09-23T13:43:25.624Z",
"dateUpdated": "2026-10-20T17:04:52.595Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-95108 (GCVE-0-2026-95108)
Vulnerability from cvelistv5
Published
2026-10-20 15:19
Modified
2026-10-20 17:06
Severity ?
VLAI Severity ?
EPSS score ?
CWE
Summary
One logical thread of a user-mode ThreadX module costs the Module Manager's shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread's system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module's allocation list.
The Module Manager's thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop — every state transition valid, every service returning `TX_SUCCESS` — removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system.
Vulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`.
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Eclipse Foundation | Eclipse ThreadX |
Version: 6.0.1 ≤ 6.5.1.202602a |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-95108",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-20T17:05:59.302618Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T17:06:10.079Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageName": "ThreadX",
"product": "Eclipse ThreadX",
"vendor": "Eclipse Foundation",
"versions": [
{
"lessThanOrEqual": "6.5.1.202602a",
"status": "affected",
"version": "6.0.1",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.5.2.202603"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "fdesbiens"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eOne logical thread of a user-mode ThreadX module costs the Module Manager\u0027s shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread\u0027s system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module\u0027s allocation list.\u003c/p\u003e\u003cp\u003eThe Module Manager\u0027s thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop \u2014 every state transition valid, every service returning `TX_SUCCESS` \u2014 removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system.\u003c/p\u003e\u003cp\u003eVulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`.\u003c/p\u003e"
}
],
"value": "One logical thread of a user-mode ThreadX module costs the Module Manager\u0027s shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread\u0027s system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module\u0027s allocation list.\n\n\n\nThe Module Manager\u0027s thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop \u2014 every state transition valid, every service returning `TX_SUCCESS` \u2014 removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system.\n\n\n\nVulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 6.8,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-400",
"description": "CWE-400 Uncontrolled Resource Consumption",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-772",
"description": "CWE-772 Missing Release of Resource after Effective Lifetime",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T15:19:16.940Z",
"orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"shortName": "eclipse"
},
"references": [
{
"url": "https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-9hhf-6357-hpgq"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Deleting a user-mode module thread leaks its privileged kernel stack",
"x_generator": {
"engine": "Vulnogram 1.0.5"
}
}
},
"cveMetadata": {
"assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"assignerShortName": "eclipse",
"cveId": "CVE-2026-95108",
"datePublished": "2026-10-20T15:19:16.940Z",
"dateReserved": "2026-09-23T13:42:24.310Z",
"dateUpdated": "2026-10-20T17:06:10.079Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-94024 (GCVE-0-2026-94024)
Vulnerability from cvelistv5
Published
2026-10-20 15:18
Modified
2026-10-20 17:01
Severity ?
VLAI Severity ?
EPSS score ?
Summary
The Module Manager's object lookup validated one byte of a memory-protected module's search name and then walked as much of it as the module declared, in privileged mode, with the kernel's preemption count raised. Both lookup dispatchers are affected: the recommended `txm_module_object_pointer_get_extended` is handed a length and does not use it to bound the buffer, and the deprecated `txm_module_object_pointer_get` supplies the largest value a `UINT` can hold, so it removes the bound rather than lacking one.
A module can make the walk unbounded without knowing anything about the memory it reaches, and where the walk reaches memory a privileged read cannot take, the resulting fault leaves the kernel unable to preempt for the rest of the system's life.
Vulnerable functions: `_txm_module_manager_txm_module_object_pointer_get_dispatch`, `_txm_module_manager_txm_module_object_pointer_get_extended_dispatch` (both in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`) and `_txm_module_manager_object_name_compare` (`common_modules/module_manager/src/txm_module_manager_util.c`).
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Eclipse Foundation | Eclipse ThreadX |
Version: 6.0.1 ≤ 6.5.1.202602a |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-94024",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-20T17:00:57.744851Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T17:01:07.513Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageName": "ThreadX",
"product": "Eclipse ThreadX",
"vendor": "Eclipse Foundation",
"versions": [
{
"lessThanOrEqual": "6.5.1.202602a",
"status": "affected",
"version": "6.0.1",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.5.2.202603"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "fdesbiens"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe Module Manager\u0027s object lookup validated one byte of a memory-protected module\u0027s search name and then walked as much of it as the module declared, in privileged mode, with the kernel\u0027s preemption count raised. Both lookup dispatchers are affected: the recommended `txm_module_object_pointer_get_extended` is handed a length and does not use it to bound the buffer, and the deprecated `txm_module_object_pointer_get` supplies the largest value a `UINT` can hold, so it removes the bound rather than lacking one.\u003c/p\u003e\u003cp\u003eA module can make the walk unbounded without knowing anything about the memory it reaches, and where the walk reaches memory a privileged read cannot take, the resulting fault leaves the kernel unable to preempt for the rest of the system\u0027s life.\u003c/p\u003e\u003cp\u003eVulnerable functions: `_txm_module_manager_txm_module_object_pointer_get_dispatch`, `_txm_module_manager_txm_module_object_pointer_get_extended_dispatch` (both in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`) and `_txm_module_manager_object_name_compare` (`common_modules/module_manager/src/txm_module_manager_util.c`).\u003c/p\u003e"
}
],
"value": "The Module Manager\u0027s object lookup validated one byte of a memory-protected module\u0027s search name and then walked as much of it as the module declared, in privileged mode, with the kernel\u0027s preemption count raised. Both lookup dispatchers are affected: the recommended `txm_module_object_pointer_get_extended` is handed a length and does not use it to bound the buffer, and the deprecated `txm_module_object_pointer_get` supplies the largest value a `UINT` can hold, so it removes the bound rather than lacking one.\n\n\n\nA module can make the walk unbounded without knowing anything about the memory it reaches, and where the walk reaches memory a privileged read cannot take, the resulting fault leaves the kernel unable to preempt for the rest of the system\u0027s life.\n\n\n\nVulnerable functions: `_txm_module_manager_txm_module_object_pointer_get_dispatch`, `_txm_module_manager_txm_module_object_pointer_get_extended_dispatch` (both in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`) and `_txm_module_manager_object_name_compare` (`common_modules/module_manager/src/txm_module_manager_util.c`)."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "CWE-125 Out-of-bounds Read",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-1284",
"description": "CWE-1284 Improper Validation of Specified Quantity in Input",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T15:18:28.242Z",
"orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"shortName": "eclipse"
},
"references": [
{
"url": "https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-39rx-hq8c-4px8"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Module Manager object lookup validates one byte of a module\u0027s search name",
"x_generator": {
"engine": "Vulnogram 1.0.5"
}
}
},
"cveMetadata": {
"assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"assignerShortName": "eclipse",
"cveId": "CVE-2026-94024",
"datePublished": "2026-10-20T15:18:28.242Z",
"dateReserved": "2026-09-23T13:42:24.317Z",
"dateUpdated": "2026-10-20T17:01:07.513Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-94023 (GCVE-0-2026-94023)
Vulnerability from cvelistv5
Published
2026-10-20 15:18
Modified
2026-10-20 17:03
Severity ?
VLAI Severity ?
EPSS score ?
Summary
A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one question about the pointer: does the object lie outside the module's own code and data. That is the policy for *using* an object, and using an object a module does not own is supported and intended — `txm_module_object_pointer_get_extended` searches the system's created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a shared queue, take a shared semaphore or get a shared mutex.
Destroying one of those is not sharing it. A module could name any object it had a pointer to and have the privileged dispatcher delete it.
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Eclipse Foundation | Eclipse ThreadX |
Version: 6.0.1 ≤ 6.5.1.202602a |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-94023",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-20T17:03:38.985757Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T17:03:48.170Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageName": "ThreadX",
"product": "Eclipse ThreadX",
"vendor": "Eclipse Foundation",
"versions": [
{
"lessThanOrEqual": "6.5.1.202602a",
"status": "affected",
"version": "6.0.1",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.5.2.202603"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "fdesbiens"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA ThreadX module reaches a kernel object\u0027s delete service through the Module Manager\u0027s dispatch layer, which asked one question about the pointer: does the object lie outside the module\u0027s own code and data. That is the policy for *using* an object, and using an object a module does not own is supported and intended \u2014 `txm_module_object_pointer_get_extended` searches the system\u0027s created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a shared queue, take a shared semaphore or get a shared mutex.\u003c/p\u003e\u003cp\u003eDestroying one of those is not sharing it. A module could name any object it had a pointer to and have the privileged dispatcher delete it.\u003c/p\u003e"
}
],
"value": "A ThreadX module reaches a kernel object\u0027s delete service through the Module Manager\u0027s dispatch layer, which asked one question about the pointer: does the object lie outside the module\u0027s own code and data. That is the policy for *using* an object, and using an object a module does not own is supported and intended \u2014 `txm_module_object_pointer_get_extended` searches the system\u0027s created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a shared queue, take a shared semaphore or get a shared mutex.\n\n\n\nDestroying one of those is not sharing it. A module could name any object it had a pointer to and have the privileged dispatcher delete it."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "CWE-125 Out-of-bounds Read",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T15:18:09.957Z",
"orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"shortName": "eclipse"
},
"references": [
{
"url": "https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-36vf-7cx6-9f9j"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Module delete dispatchers do not enforce kernel-object ownership before irreversible deletion",
"x_generator": {
"engine": "Vulnogram 1.0.5"
}
}
},
"cveMetadata": {
"assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"assignerShortName": "eclipse",
"cveId": "CVE-2026-94023",
"datePublished": "2026-10-20T15:18:09.957Z",
"dateReserved": "2026-09-23T13:43:04.333Z",
"dateUpdated": "2026-10-20T17:03:48.170Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-95109 (GCVE-0-2026-95109)
Vulnerability from cvelistv5
Published
2026-10-20 15:17
Modified
2026-10-20 17:07
Severity ?
VLAI Severity ?
EPSS score ?
Summary
The Cortex-A7 MMU Modules port validates a caller-supplied buffer by translating **one address** — the first byte. The common Module Manager hands its range check the module instance, the start address and the complete byte size; the Cortex-A7 implementation discarded the instance and the size and asked the MMU a single question about the start.
A memory-protected module therefore passed any range whose first byte was user-readable, however far the rest of it reached. Privileged dispatch code then read or wrote the whole range. Because every protected-module dispatcher that consumes a buffer or an extra-parameter array goes through this one macro, the defect is not in any individual service: it is in the primitive all of them rely on.
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Eclipse Foundation | Eclipse ThreadX |
Version: 6.1 < |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-95109",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-20T17:07:06.551689Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T17:07:15.973Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageName": "ThreadX",
"product": "Eclipse ThreadX",
"vendor": "Eclipse Foundation",
"versions": [
{
"lessThanOrEqual": "6.5.1.202602a",
"status": "affected",
"version": "6.1",
"versionType": "custom"
},
{
"status": "unaffected",
"version": "6.5.2.202603"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "fdesbiens"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe Cortex-A7 MMU Modules port validates a caller-supplied buffer by translating **one address** \u2014 the first byte. The common Module Manager hands its range check the module instance, the start address and the complete byte size; the Cortex-A7 implementation discarded the instance and the size and asked the MMU a single question about the start.\u003c/p\u003e\u003cp\u003eA memory-protected module therefore passed any range whose first byte was user-readable, however far the rest of it reached. Privileged dispatch code then read or wrote the whole range. Because every protected-module dispatcher that consumes a buffer or an extra-parameter array goes through this one macro, the defect is not in any individual service: it is in the primitive all of them rely on.\u003c/p\u003e"
}
],
"value": "The Cortex-A7 MMU Modules port validates a caller-supplied buffer by translating **one address** \u2014 the first byte. The common Module Manager hands its range check the module instance, the start address and the complete byte size; the Cortex-A7 implementation discarded the instance and the size and asked the MMU a single question about the start.\n\n\n\nA memory-protected module therefore passed any range whose first byte was user-readable, however far the rest of it reached. Privileged dispatch code then read or wrote the whole range. Because every protected-module dispatcher that consumes a buffer or an extra-parameter array goes through this one macro, the defect is not in any individual service: it is in the primitive all of them rely on."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 8.5,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "CWE-125 Out-of-bounds Read",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-787",
"description": "CWE-787 Out-of-bounds Write",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T15:17:20.023Z",
"orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"shortName": "eclipse"
},
"references": [
{
"url": "https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-fvp6-37q5-c648"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Cortex-A7 module data validation checks only the first address of a caller-supplied range",
"x_generator": {
"engine": "Vulnogram 1.0.5"
}
}
},
"cveMetadata": {
"assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"assignerShortName": "eclipse",
"cveId": "CVE-2026-95109",
"datePublished": "2026-10-20T15:17:20.023Z",
"dateReserved": "2026-09-23T13:43:25.621Z",
"dateUpdated": "2026-10-20T17:07:15.973Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-94192 (GCVE-0-2026-94192)
Vulnerability from cvelistv5
Published
2026-10-20 15:15
Modified
2026-10-20 17:04
Severity ?
VLAI Severity ?
EPSS score ?
Summary
A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with `txm_module_object_deallocate`. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation.
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Eclipse Foundation | Eclipse ThreadX |
Version: 6.0.1 ≤ 6.5.1.202602a |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-94192",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-20T17:04:14.458746Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T17:04:24.537Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageName": "ThreadX",
"product": "Eclipse ThreadX",
"vendor": "Eclipse Foundation",
"versions": [
{
"lessThanOrEqual": "6.5.1.202602a",
"status": "affected",
"version": "6.0.1",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.5.2.202603"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "fdesbiens"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA ThreadX module allocates the control blocks of its kernel objects from the Module Manager\u0027s object pool, and can ask for that memory back by address with `txm_module_object_deallocate`. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation.\u003c/p\u003e"
}
],
"value": "A ThreadX module allocates the control blocks of its kernel objects from the Module Manager\u0027s object pool, and can ask for that memory back by address with `txm_module_object_deallocate`. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 8.5,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-416",
"description": "CWE-416 Use After Free",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-664",
"description": "CWE-664 Improper Control of a Resource Through its Lifetime",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T15:15:06.222Z",
"orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"shortName": "eclipse"
},
"references": [
{
"url": "https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-57mf-w87f-rq7m"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Module object deallocation can free a live ThreadX kernel object",
"x_generator": {
"engine": "Vulnogram 1.0.5"
}
}
},
"cveMetadata": {
"assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"assignerShortName": "eclipse",
"cveId": "CVE-2026-94192",
"datePublished": "2026-10-20T15:15:06.222Z",
"dateReserved": "2026-09-23T13:42:24.290Z",
"dateUpdated": "2026-10-20T17:04:24.537Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-95111 (GCVE-0-2026-95111)
Vulnerability from cvelistv5
Published
2026-10-20 14:35
Modified
2026-10-20 15:34
Severity ?
VLAI Severity ?
EPSS score ?
Summary
A memory-protected ThreadX module's queue request reaches the Module Manager's dispatch layer, which decides how much of the module's buffer the privileged queue copy may touch and hands that extent to the module port's range check. A queue's `tx_queue_message_size` is a count of `ULONG`s and the copy moves that many words, so the extent is `message_size * sizeof(ULONG)` bytes.
The front-send dispatcher passed the word count itself. `tx_queue_send` and `tx_queue_receive`, either side of it in the same header, have always multiplied.
A source buffer ending `message_size` bytes into memory the module may read was therefore accepted, and `_txe_queue_front_send` then read `message_size * sizeof(ULONG)` bytes from it in privileged mode — `3 * message_size` bytes past the end of what the module is allowed to read. The words are written into the queue's message area, so a module that can receive from that queue reads them back.
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Eclipse Foundation | Eclipse ThreadX |
Version: 6.0.1 ≤ 6.5.1.202602a |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-95111",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-20T15:34:29.349332Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T15:34:45.488Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageName": "ThreadX",
"product": "Eclipse ThreadX",
"vendor": "Eclipse Foundation",
"versions": [
{
"lessThanOrEqual": "6.5.1.202602a",
"status": "affected",
"version": "6.0.1",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.5.2.202603"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "fdesbiens"
},
{
"lang": "en",
"type": "finder",
"value": "SounLabs"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA memory-protected ThreadX module\u0027s queue request reaches the Module Manager\u0027s dispatch layer, which decides how much of the module\u0027s buffer the privileged queue copy may touch and hands that extent to the module port\u0027s range check. A queue\u0027s `tx_queue_message_size` is a count of `ULONG`s and the copy moves that many words, so the extent is `message_size * sizeof(ULONG)` bytes.\u003c/p\u003e\u003cp\u003eThe front-send dispatcher passed the word count itself. `tx_queue_send` and `tx_queue_receive`, either side of it in the same header, have always multiplied.\u003c/p\u003e\u003cp\u003eA source buffer ending `message_size` bytes into memory the module may read was therefore accepted, and `_txe_queue_front_send` then read `message_size * sizeof(ULONG)` bytes from it in privileged mode \u2014 `3 * message_size` bytes past the end of what the module is allowed to read. The words are written into the queue\u0027s message area, so a module that can receive from that queue reads them back.\u003c/p\u003e"
}
],
"value": "A memory-protected ThreadX module\u0027s queue request reaches the Module Manager\u0027s dispatch layer, which decides how much of the module\u0027s buffer the privileged queue copy may touch and hands that extent to the module port\u0027s range check. A queue\u0027s `tx_queue_message_size` is a count of `ULONG`s and the copy moves that many words, so the extent is `message_size * sizeof(ULONG)` bytes.\n\n\n\nThe front-send dispatcher passed the word count itself. `tx_queue_send` and `tx_queue_receive`, either side of it in the same header, have always multiplied.\n\n\n\nA source buffer ending `message_size` bytes into memory the module may read was therefore accepted, and `_txe_queue_front_send` then read `message_size * sizeof(ULONG)` bytes from it in privileged mode \u2014 `3 * message_size` bytes past the end of what the module is allowed to read. The words are written into the queue\u0027s message area, so a module that can receive from that queue reads them back."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 4.8,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "CWE-125 Out-of-bounds Read",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-131",
"description": "CWE-131 Incorrect Calculation of Buffer Size",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T14:35:40.629Z",
"orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"shortName": "eclipse"
},
"references": [
{
"url": "https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-rrg6-24r9-wqpm"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Module queue front-send validates a word count as a byte count",
"x_generator": {
"engine": "Vulnogram 1.0.5"
}
}
},
"cveMetadata": {
"assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"assignerShortName": "eclipse",
"cveId": "CVE-2026-95111",
"datePublished": "2026-10-20T14:35:40.629Z",
"dateReserved": "2026-09-23T13:43:25.627Z",
"dateUpdated": "2026-10-20T15:34:45.488Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-0648 (GCVE-0-2026-0648)
Vulnerability from cvelistv5
Published
2026-01-27 15:40
Modified
2026-01-27 15:53
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-253 - Incorrect Check of Function Return Value
Summary
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.
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Eclipse Foundation | Eclipse ThreadX |
Version: 6.1.7 ≤ 6.4.3 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-0648",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-01-27T15:53:06.324106Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-01-27T15:53:36.128Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Eclipse ThreadX",
"repo": "https://github.com/eclipse-threadx/threadx",
"vendor": "Eclipse Foundation",
"versions": [
{
"lessThanOrEqual": "6.4.3",
"status": "affected",
"version": "6.1.7",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Lavine Yue"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe vulnerability stems from an incorrect error-checking logic in the \u003ccode\u003eCreateCounter()\u003c/code\u003e\u0026nbsp;function (in \u003ccode\u003ethreadx/utility/rtos_compatibility_layers/OSEK/tx_osek.c\u003c/code\u003e) when handling the return value of \u003ccode\u003eosek_get_counter()\u003c/code\u003e. Specifically, the current code checks if \u003ccode\u003ecntr_id\u003c/code\u003e\u0026nbsp;equals \u003ccode\u003e0u\u003c/code\u003e\u0026nbsp;to determine failure, but \u003ccode\u003e@osek_get_counter()\u003c/code\u003e\u0026nbsp;actually returns \u003ccode\u003eE_OS_SYS_STACK\u003c/code\u003e\u0026nbsp;(defined as \u003ccode\u003e12U\u003c/code\u003e) when it fails. This mismatch causes the error branch to never execute even when the counter pool is exhausted.\u003c/p\u003e\u003cp\u003eAs a result, when the counter pool is depleted, the code proceeds to cast the error code (\u003ccode\u003e12U\u003c/code\u003e) to a pointer (\u003ccode\u003eOSEK_COUNTER *\u003c/code\u003e), creating a wild pointer. Subsequent writes to members of this pointer lead to writes to illegal memory addresses (e.g., \u003ccode\u003e0x0000000C\u003c/code\u003e), which can trigger immediate HardFaults or silent memory corruption.\u003c/p\u003e\u003cp\u003eThis vulnerability poses significant risks, including potential denial-of-service attacks (via repeated calls to exhaust the counter pool) and unauthorized memory access.\u003c/p\u003e\u003cbr\u003e"
}
],
"value": "The vulnerability stems from an incorrect error-checking logic in the CreateCounter()\u00a0function (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\u00a0equals 0u\u00a0to determine failure, but @osek_get_counter()\u00a0actually returns E_OS_SYS_STACK\u00a0(defined as 12U) when it fails. This mismatch causes the error branch to never execute even when the counter pool is exhausted.\n\nAs 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.\n\nThis vulnerability poses significant risks, including potential denial-of-service attacks (via repeated calls to exhaust the counter pool) and unauthorized memory access."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-253",
"description": "CWE-253 Incorrect Check of Function Return Value",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-01-27T15:40:31.216Z",
"orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"shortName": "eclipse"
},
"references": [
{
"url": "https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-xj75-fc68-h4rw"
}
],
"source": {
"discovery": "UNKNOWN"
},
"x_generator": {
"engine": "Vulnogram 0.5.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"assignerShortName": "eclipse",
"cveId": "CVE-2026-0648",
"datePublished": "2026-01-27T15:40:31.216Z",
"dateReserved": "2026-01-06T16:19:46.498Z",
"dateUpdated": "2026-01-27T15:53:36.128Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}