JPEG decoder: a duplicate SOF0 after SOS publishes a pixelmap that misreports its own allocation size
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 - GUIX | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Eclipse | Threadx Guix |
|
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.159% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Eclipse
Eclipse threadx Guix |
|
| Vendors & Products |
Eclipse
Eclipse threadx Guix |
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | The GUIX JPEG software decoder enforces no ordering on JPEG markers. A file that places a second `SOF0` frame header after `SOS` re-runs the frame header parser after the output buffer has already been allocated and its geometry latched. The decoder returns `GX_SUCCESS` and publishes a `GX_PIXELMAP` whose reported dimensions and `data_size` exceed the allocation behind it. Any consumer that trusts the returned structure reads out of bounds, including GUIX's own display drivers, reached through the ordinary draw path. Reproduces in the shipped default configuration; `GX_SOFTWARE_DECODER_SUPPORT` is enabled by default. | |
| Title | JPEG decoder: a duplicate SOF0 after SOS publishes a pixelmap that misreports its own allocation size | |
| Weaknesses | CWE-125 | |
| References |
| |
| Metrics |
cvssV4_0
|