Analysis and contextual insights are available on OpenCVE Cloud.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
No advisories yet.
Tue, 20 Oct 2026 17:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Tue, 20 Oct 2026 15:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Module object deallocation can free a live ThreadX kernel object | |
| Weaknesses | CWE-416 CWE-664 |
|
| References |
| |
| Metrics |
cvssV4_0
|
Subscriptions
No data.
Status: PUBLISHED
Assigner: eclipse
Published:
Updated: 2026-10-20T17:04:24.537Z
Reserved: 2026-09-23T13:42:24.290Z
Link: CVE-2026-94192
Updated: 2026-10-20T17:04:20.477Z
Status : Received
Published: 2026-10-20T16:17:18.030
Modified: 2026-10-20T18:17:23.700
Link: CVE-2026-94192
No data.
OpenCVE Enrichment
Updated: 2026-10-20T18:15:14Z