Live › vulnerability › CVE-2026-91059
Go to dashboardThe GUIX JPEG software decoder accepts a second SOF0 frame header after SOS, re-running the parser after the output buffer is sized. The decoder then reports pixel dimensions larger than the real allocation, so consumers such as GUIX display drivers read past the buffer.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Applications that decode JPEG images with GUIX's built-in software decoder and pass the result to the draw path, typically embedded or RTOS devices with displays. Systems that never decode untrusted JPEG files, or that disable the software decoder, are likely not exposed. Whether a firmware image in the field includes the affected code is unknown.
No product ranges from the sources yet.
GX_SOFTWARE_DECODER_SUPPORT enabled (enabled by default)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-91059")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.