Eclipse ThreadX CVE-2025-55078

Requires the Eclipse ThreadX loadable Modules feature to be in use, and the attacker must already be able to execute low-privilege code inside a module (PR:L) that calls one of the affected system calls with a pointer aimed at a reserved or unmapped region. The flaw is that the existing pointer validation does not verify the pointer falls outside the module memory region. Limiting factors: exploitation is strictly local (AV:L, no network reachability), a specific attack requirement applies (AT:P, dependent on module memory layout), it needs pre-existing module-level code execution rather than being remote-unauthenticated, and the impact is confined to availability (a crash) with no data disclosure or modification. Devices built without the Modules feature are not affected.

This is a moderate-severity local denial-of-service issue, not a priority emergency. The provided CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:L/UI:N, VA:H with VC:N/VI:N) scores 5.7 and is internally consistent with the description: exploitation is local, requires some existing privilege (PR:L - the attacker must already run code within a ThreadX module), carries a present attack requirement (AT:P, reflecting dependence on module memory layout), and impacts availability only (a crash), with no confidentiality or integrity loss. The EPSS probability is very low (0.17%, 6th percentile), and the CVE is NOT in CISA KEV, so there is no evidence of active exploitation despite the existence of public exploit material in the GHSA advisory. The signals are therefore mutually reinforcing rather than conflicting: low EPSS + no KEV + local-only + availability-only + privilege prerequisite all point to a bounded, low-urgency bug. POC availability is a distinct signal from exploitation and here reflects a vendor-published security advisory, not a weaponized widespread campaign. Note that CWE-233 (improper handling of parameters) and the availability-only impact mean this is a robustness/input-validation defect, not a code-execution flaw.

On a device running Eclipse ThreadX with the loadable Modules feature, an attacker (or faulty/malicious module) already executing low-privilege code within a module invokes a vulnerable system call passing a pointer that resolves to a reserved or unmapped memory region. Because the kernel's pointer check fails to confirm the pointer lies outside the module memory region, the dereference triggers a fault and crashes the RTOS. Public exploit/advisory material exists (Eclipse GHSA-wcfg-5jpf-hhxq), lowering the effort to reproduce the crash.