Eclipse ThreadX GUIX CVE-2026-92454

Requires that the application be built with the default GX_SOFTWARE_DECODER_SUPPORT enabled AND that it pass an attacker-controlled JPEG to the GUIX software JPEG decoder (user interaction / UI:R - the image must be opened, loaded, or rendered). The two concrete triggers are: (1) a JPEG marker segment of one of four types that is truncated shorter than the fields the decoder reads, triggering the out-of-bounds read; and (2) a JPEG declaring a zero chroma sampling factor, triggering the non-terminating block-decode loop. Limiting factors: the vector is local (AV:L) and exploitation only occurs if the embedding product actually decodes externally-influenced images - a product that only renders trusted, build-time image assets is not realistically exposed; confidentiality impact of the over-read is low (C:L), and the dominant real-world outcome is an availability/DoS device hang.

This is a moderate-severity, locally-triggered memory-safety flaw in the GUIX software JPEG decoder, best treated as a robustness/availability bug rather than a top-tier priority. The vendor CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H, 6.1) is internally consistent with the description: exploitation requires the application to decode an attacker-supplied JPEG (UI:R), yields only a low-confidentiality out-of-bounds read (C:L, matching CWE-125) and a high-availability denial of service from the non-terminating block-decode loop (A:H). No EPSS score, KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active or widespread exploitation - the signals do not conflict, they are simply absent, which is consistent with a newly-disclosed embedded-RTOS parser bug. The main caveat is the attack vector: CVSS asserts AV:L, but in practice the real exposure depends entirely on how the embedding product feeds images to GUIX (local resource vs. image received over a network/Bluetooth/USB channel); if a product decodes remotely-sourced JPEGs, the practical reach is broader than AV:L implies - verify the data path per deployment. Overall, remediate on a normal patch cadence; the A:H device-hang is the more realistic impact than the low-value memory disclosure.

An attacker crafts a malformed JPEG - either with a truncated marker segment (APP/DQT/DHT/SOF-class) shorter than the fields the decoder reads, or with a chroma sampling factor of zero - and gets it in front of a GUIX-based application, e.g. as a firmware resource, a file on removable media, or an image received over a product's own channel. When the device decodes it with the default GX_SOFTWARE_DECODER_SUPPORT path, the truncated segment causes a read past the end of the image buffer (leaking adjacent memory or faulting) or the zero sampling factor sends the block-decode loop into a permanent hang. No public exploit code was provided in the input.