A module in ThreadX selects an allocation size and the manager adds a 16‑byte header before allocating the block. The allocation routine does not check that the sum of the requested size and the header fits within the available buffer space, so an integer overflow can occur. When the calculated size wraps on a ULONG boundary, the pool hands back a block that is too small for the header, and the manager writes past the end of the block corrupting the next byte‑pool region. This memory corruption can be leveraged to overwrite control data and potentially execute arbitrary code.

The vulnerability affects Eclipse ThreadX deployments under Eclipse Foundation. No specific version ranges are listed, implying that all releases prior to an as‑yet‑unreleased patch are possibly affected.

With a CVSS score of 7 the flaw is considered high severity. The EPSS score is not available and the vulnerability is not listed in CISA KEV, suggesting it has not been publicly exploited yet. Paradoxically, the attack vector is inferred to be local, requiring the ability to load or install a module. If an attacker can supply a malicious module, the integer and buffer overflows could corrupt adjacent memory, leading to crashes or code execution.