Eclipse Threadx Guix
Approved changes feed: RSS · Atom
cpe:2.3:a:eclipse_foundation:eclipse_threadx_-_guix:*:*:*:*:*:*:*:*part: a version: * update: *
| Vendor | Eclipse Foundation (2c315c48-0111-5572-bbde-cc70cfafb2e9) |
|---|---|
| Product | Eclipse 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
| PURL | Source | Last updated |
|---|---|---|
| No PURL mappings for this CPE yet. | ||
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
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 |
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 |
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 |
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 |
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 |
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 this panel to browse, search, copy or download the JSON record.