GUIX vulnerabilities

_gx_multi_line_text_view_display_info_get() reads one byte past the end of the application's text buffer when the given string ends with a carriage return (\r). The over-read can also cause callers to advance their index past the end of the string, producing a second over-read in _gx_multi_line_text_view_string_total_rows_compute() and a row of text not present in the source.

The GUIX software JPEG decoder reads four kinds of marker segments without checking that each is long enough to hold what it reads. A truncated segment causes a read past the caller's image buffer, and a zero chroma sampling factor makes the block decode loop non-terminating.

_gx_binres_pixelmap_table_load() in the GUIX binary resource (theme) loader indexes the pixelmap table with a value read verbatim from the resource file and never bounds it against the table size. A crafted theme drives a write of up to roughly 256 KB past the end of the table, corrupting GUIX's own memory arena.

gx_binres_theme_load() and gx_binres_font_load() take the resource as a bare GX_UBYTE * with no length, and GX_BINRES_DATA_INFO has no field to carry one. A resource declaring more data than it contains is read past its end, and an offset stored in the file is turned into a pointer without being bounded.

The GUIX binary resource loader does not validate that a font page's glyph range is well formed. A page declaring first_glyph > last_glyph causes an unsigned underflow, and an unchecked multiplication leads to allocating a buffer far smaller than the data written into it, resulting in a heap overflow with attacker-controlled glyph records.

The GUIX PNG chunk reader does not enforce chunk ordering and allows a second IHDR to be read after IDAT. The second IHDR rewrites dimensions and bit depth after the decoded-data buffer has been allocated, and the row-filter reversal pass then walks past the old allocation, causing a heap out-of-bounds write.

The GUIX JPEG software decoder enforces no ordering on JPEG markers. A file placing a second SOF0 frame header after SOS re-runs the frame header parser after the output buffer has been allocated, and the decoder returns GX_SUCCESS and publishes a GX_PIXELMAP whose dimensions and data_size exceed the allocation.

`gx_binres_theme_load()` sizes its theme buffer for the theme it was asked for, and allocates it even when the resource holds no theme with that id. A theme id at or past the theme count declared by the resource gets a buffer of zero bytes. The load pass then walks past the end of the theme table, takes whatever follows as a theme header, and writes a `GX_THEME` and its tables into that zero-byte buffer.

The GUIX binary resource (theme) loader sizes its arena and populates it in two separate passes that traverse the resource file with independent cursor arithmetic. Because `gx_page_header_data_size` is never validated against the glyph data a page actually contains, the two passes can read different page headers for the same font page, derive different glyph counts, and reserve less than the load pass writes. The excess is written past the end of the arena, with content taken verbatim from the file. The overflowed buffer is allocated by GUIX itself, through `_gx_system_memory_allocator`, rather than supplied by the caller. The public API `gx_binres_theme_load()` takes no size parameter, so no amount of caller diligence prevents this. Reproduces in the shipped default configuration; `GX_BINARY_RESOURCE_SUPPORT` is enabled by default.