CVE-2026-92446 in ThreadX
Summary
by MITRE • 10/20/2026
`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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability in the GX Binary Resource loader stems from a fundamental design flaw where resource loading functions such as gx_binres_theme_load() and gx_binres_font_load() accept data buffers represented solely by bare pointers of type GX_UBYTE without any accompanying length parameters. This architectural decision means that the loader operates with no knowledge of the actual extent or size of the memory buffer it is processing. The structure GX_BINRES_DATA_INFO, which defines how resource metadata is stored within these binary files, lacks a field to carry length information for data segments. Consequently, every read operation performed by the loader relies entirely on offsets and sizes declared directly within the file itself rather than validating them against the actual allocated buffer size. This creates a scenario where the integrity of memory access is compromised because the software trusts untrusted input values as absolute boundaries without verification.
When a crafted resource file declares more data content than what actually exists in the provided buffer, or specifies an offset that points beyond the end of the available memory region, the loader proceeds to read past the allocated boundary. This results in out-of-bounds reads, which fall under CWE-125: Out-of-bounds Read. The vulnerability does not require complex exploitation techniques such as integer underflows or wrapped multiplications to trigger; instead, a perfectly well-formed but maliciously constructed file with narrow glyph ranges can easily exploit this defect. By specifying an offset that is turned into a pointer without being bounded by the actual buffer limits, attackers can force the application to access memory regions it should not have permission to read. This behavior distinguishes the issue from other related vulnerabilities like GHSA-hgcj-22cg-4hfv, which involved underflowed glyph counts and required different exploitation conditions involving arithmetic errors rather than simple boundary violations.
The operational impact of this vulnerability is significant as out-of-bounds reads can lead to information disclosure where sensitive data residing in adjacent memory locations may be leaked through the application's output or error messages. In more severe cases, if the read operation triggers a fault due to accessing unmapped memory, it results in a denial of service by crashing the application. Furthermore, depending on how the loaded resource is subsequently used within the graphics subsystem, these invalid reads could potentially lead to further exploitation vectors such as use-after-free scenarios or logic errors that compromise system stability. The lack of input validation means that any binary file processed by this loader poses a potential risk if it originates from an untrusted source, making remote code execution theoretically possible if combined with other memory corruption primitives in the broader application context.
To mitigate this vulnerability, developers must modify the resource loading architecture to include explicit length parameters for all buffer operations. The GX_BINRES_DATA_INFO structure should be updated or supplemented with fields that carry accurate size information for each data segment. Before performing any read operation based on offsets stored in the file, the loader must validate these values against the actual size of the provided buffer. This validation ensures that no access occurs beyond the allocated memory region. Additionally implementing strict bounds checking and adding assertions during development can help catch such discrepancies early. Adopting secure coding practices aligned with CWE-20: Improper Input Validation is essential to prevent attackers from leveraging malformed binary resources to compromise system integrity or confidentiality.