Approved changes feed: RSS · Atom

cpe:2.3:a:eclipse_foundation:eclipse_threadx_-_guix:*:*:*:*:*:*:*:*

part: a version: * update: *

VendorEclipse Foundation (2c315c48-0111-5572-bbde-cc70cfafb2e9)
ProductEclipse Threadx Guix (2649703a-de06-525a-ab00-fe28c31f54d0)
Edition*
Language*
Software edition*
Target software*
Target hardware*
Other*

Notes

Imported from gcve-enriched-dumps CVE data

PURL mappings

PURLSourceLast updated
No PURL mappings for this CPE yet.

Vulnerability references

IdentifiercpeApplicabilitySubmitteddb.gcve.eu detailsRationale
CVE:CVE-2026-92454 vulnerable 2026-11-03 10:16:22.430561 JPEG decoder: truncated segments are read past the image buffer, and a zero sampling factor hangs the decode
MEDIUM (6.1)
The GUIX software JPEG decoder reads four kinds of marker segment without checking that each is long enough to hold what it reads. A truncated segment is therefore read past the end of the caller's image buffer. Separately, a zero chroma sampling factor makes the block decode loop non-terminating. Both reproduce in the default configuration, in which `GX_SOFTWARE_DECODER_SUPPORT` is enabled.
Published: 2026-10-20T14:58:36.821Z
Updated: 2026-10-20T15:21:42.800Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2026-92449 vulnerable 2026-11-03 10:16:21.571951 Binary resource loader: unbounded map_id from a theme file causes a heap out-of-bounds write in the GUIX-allocated arena
`_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. The overflowed buffer is allocated by GUIX itself, through `_gx_system_memory_allocator`, rather than supplied by the caller, so the loader corrupts its own arena. 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.
Published: 2026-10-20T14:51:24.582Z
Updated: 2026-10-20T15:27:55.848Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2026-92446 vulnerable 2026-11-03 10:16:21.292986 GUIX binary resource loader reads past the end of a resource, because no length for it ever reaches the loader
`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. Every read is therefore performed at an offset the file itself chose, against a buffer whose extent the loader does not know. A resource that declares 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. This is a distinct defect from GHSA-hgcj-22cg-4hfv, which was an underflowed glyph count. It needs no underflow and no wrapped multiply: a perfectly well-formed, narrow glyph range reaches it.
Published: 2026-10-20T14:52:45.765Z
Updated: 2026-10-20T15:26:36.082Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2026-91186 vulnerable 2026-11-03 10:15:57.788548 PNG decoder: a duplicate IHDR chunk after IDAT resizes the image after allocation, causing a heap out-of-bounds write
The PNG chunk reader has no notion of chunk ordering. It records whether an IDAT has been seen and whether a tRNS has already supplied transparency, but nothing prevents an IHDR being read a second time. A PNG carries exactly one IHDR and it is the first chunk. A file that places a second one after IDAT rewrites the image width, height, bit depth and pixel depth *after* the decoded-data buffer has already been allocated and filled from the original values. The pass that reverses the PNG row filters then derives its own extent from the new dimensions and walks the old allocation, moving image bytes past the end of it. The buffer is allocated by GUIX rather than supplied by the caller, so the application has no way to size it defensively. The decoder is compiled in by default.
Published: 2026-10-20T14:47:52.216Z
Updated: 2026-10-20T15:28:59.237Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2026-91059 vulnerable 2026-11-03 10:15:57.368127 JPEG decoder: a duplicate SOF0 after SOS publishes a pixelmap that misreports its own allocation size
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.
Published: 2026-10-20T14:54:37.119Z
Updated: 2026-10-20T15:24:14.860Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2026-91057 vulnerable 2026-11-03 10:15:57.016359 db.gcve.eu details were skipped to keep the page responsive. Imported from gcve-enriched-dumps CVE data
CVE:CVE-2026-91189 vulnerable 2026-11-03 10:15:56.966310 db.gcve.eu details were skipped to keep the page responsive. Imported from gcve-enriched-dumps CVE data

Contribute

You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.

Inspect record JSON

Open JSON directly

Open this panel to browse, search, copy or download the JSON record.