CVE-2026-91189 in ThreadX
Summary
by MITRE • 10/20/2026
The GUIX binary resource loader never checks that a font page's glyph range is well formed. `gx_page_header_first_glyph` and `gx_page_header_last_glyph` are read verbatim from the file and only the upper bound of `last_glyph` is validated, so a page declaring `first_glyph > last_glyph` makes `last - first + 1` underflow to a very large unsigned count.
That count is multiplied by a glyph record size to reserve the load buffer, and the multiply is unchecked, so it wraps to a small value and the loader allocates a buffer far smaller than the data it is about to write. The load pass then recomputes the count in a narrower type and writes attacker-controlled glyph records into the undersized buffer.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability resides within the binary resource loader of the GUIX graphics library, specifically affecting the handling of font page definitions during initialization. This flaw is categorized under CWE-190 Integer Overflow or Wraparound and CWE-20 Improper Input Validation, as it stems from a failure to properly validate input data before performing arithmetic operations that determine memory allocation sizes. The core issue arises when processing glyph ranges defined in the font file header. Specifically, the loader reads two values, first_glyph and last_glyph, directly from the external resource without rigorous structural validation of their relationship. While the implementation performs a check on the upper bound of last_glyph to ensure it does not exceed certain limits, it neglects to verify that first_glyph is less than or equal to last_glyph. This oversight allows an attacker to craft a malicious font file where the declared starting glyph index exceeds the ending glyph index.
When such a malformed page header is processed, the calculation for the number of glyphs in the range relies on the formula last minus first plus one. Because these values are treated as unsigned integers, if first_glyph is greater than last_glyph, this subtraction results in an underflow. The result wraps around to a very large positive integer close to the maximum value representable by the data type. This inflated count represents the number of glyph records that the loader believes it needs to process and store. Consequently, this erroneous magnitude drives subsequent memory allocation logic intended to reserve space for loading these glyphs into an internal buffer structure.
The severity of the vulnerability is compounded by a secondary integer overflow during the calculation of the required buffer size. The system multiplies the inflated glyph count by the fixed size of a single glyph record to determine the total bytes needed. Since both operands are large unsigned integers, their product exceeds the capacity of the variable type used for storage, causing another wraparound or truncation event. This results in a final allocated buffer size that is drastically smaller than what was originally calculated and intended by the logic flow. The loader proceeds with this insufficiently sized allocation based on the wrapped-around value rather than the true required memory footprint derived from the raw input data.
Following the flawed allocation, the loading routine enters its execution phase to populate the newly created buffer. During this pass, the system recomputes or utilizes the original large count of glyphs and proceeds to write attacker-controlled glyph record structures into the undersized destination buffer. Because the allocated memory region is significantly smaller than the volume of data being written, a classic heap-based buffer overflow occurs. This allows an adversary with control over the font resource file to overwrite adjacent memory regions on the heap. Such out-of-bounds writes can corrupt internal library state variables, alter function pointers stored in nearby structures, or leak sensitive information through partial overwrites depending on the specific layout of the GUIX runtime environment and the target operating system's memory management policies.
From a threat modeling perspective aligned with MITRE ATT&CK techniques, this vulnerability facilitates initial code execution via exploitation of improper input validation leading to buffer overflow (T1203). The attacker leverages the lack of boundary checks on integer arithmetic operations to bypass standard safety mechanisms inherent in safe programming practices. In embedded systems or environments where GUIX is commonly deployed, such as IoT devices or industrial control interfaces, successful exploitation could lead to complete system compromise, denial of service through memory corruption crashes, or privilege escalation if the application runs with elevated permissions. The impact extends beyond simple data integrity loss, potentially allowing remote attackers to inject and execute arbitrary code by carefully crafting font files that trigger these specific arithmetic anomalies during resource loading phases.
Mitigation strategies must focus on rigorous input validation at the point of entry for all external resources processed by the GUIX loader. Developers should implement explicit checks ensuring that first_glyph is less than or equal to last_glyph before performing any subtraction operations involving these values. Furthermore, it is critical to use safe arithmetic functions or compiler flags that detect integer overflows and underflows during compilation. When calculating buffer sizes based on user-supplied counts multiplied by record sizes, the code must verify that no overflow occurs prior to allocation. Additionally, employing static analysis tools configured to flag potential integer wraparounds in C/C++ projects can help identify similar patterns across the codebase. Updating to patched versions of GUIX where these validation checks have been enforced is essential for maintaining security posture against crafted malicious font assets designed to exploit this specific logical flaw.