ThreadX Modules invokes trace-full callbacks after module unload
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Eclipse Foundation | Eclipse ThreadX | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Eclipse | Threadx |
|
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.107% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Eclipse
Eclipse threadx |
|
| Vendors & Products |
Eclipse
Eclipse threadx |
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, ThreadX Modules does not revoke a module's trace-buffer-full callback when the module is stopped and unloaded. With event tracing enabled and a kernel-owned trace buffer still active, a later buffer wrap invokes the callback from privileged thread context after the module's code has been released, so a user-mode module can have its code run with kernel privileges after unload, or, once the memory is reused, redirect control flow or cause a fault. | |
| Title | ThreadX Modules invokes trace-full callbacks after module unload | |
| Weaknesses | CWE-416 | |
| References |
| |
| Metrics |
cvssV4_0
|