CVE-2025-15534: 
NixOS vulnerability analysis and mitigation

CVE-2025-15534 is an integer overflow vulnerability in the LoadFontData() function of raysan5 raylib, located in src/rtext.c. It affects raylib versions up to and including commit 909f040 (prior to January 1, 2026). The flaw was discovered and reported on December 24, 2025, with the fix merged on January 1, 2026, and the CVE published on January 18, 2026. NVD assigns a CVSS v3.1 base score of 7.8 (High) for this local attack vector vulnerability, while the CNA (VulDB) rates it 5.3 (Medium) under CVSS v3.1 and 1.9 (Low) under CVSS v4.0 (GitHub Issue, Red Hat Advisory).

The root cause is an integer overflow (CWE-190) in LoadFontData() at src/rtext.c:747, where a malicious or malformed font file can cause stbtt_GetCodepointHMetrics() to return a negative advanceX value. This negative value is then passed directly to RL_CALLOC(glyphs[k].advanceX * fontSize, 2), causing a calloc parameter overflow (e.g., -14624 * 2) that cannot be represented as size_t. With AddressSanitizer enabled, the runtime aborts; in a release build, the invalid allocation propagates downstream, causing a segmentation fault in GenImageFontAtlas() when it dereferences an invalid or NULL pointer. The fix (commit 5a3391f) adds a guard to clamp negative advanceX values to zero and conditionally skips the allocation, along with bounds checks in GenImageFontAtlas() to prevent heap underflow and overflow (GitHub Issue, GitHub Commit).

A low-privileged local attacker who can supply a crafted font file to an application using a vulnerable version of raylib can trigger memory corruption, potentially leading to application crashes (denial of service), sensitive memory disclosure, or modification of application state. The primary confirmed impact is a segmentation fault in GenImageFontAtlas(), causing availability loss; however, the memory corruption conditions could theoretically be leveraged for further exploitation depending on the application context. The vulnerability is scoped to the local system and does not provide a direct path to remote code execution or lateral movement (Feedly, GitHub Issue).

A public proof-of-concept exploit (a malicious font file segv1) is available on GitHub, and the issue tracker itself serves as a technical write-up with reproduction steps. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.013% (0.000130), reflecting very low probability of exploitation in the near term. Exploitation requires local access and low privileges, limiting the practical attack surface (GitHub PoC, Feedly).

1. Prepare a malicious font file: Craft or obtain a specially malformed font file (e.g., the public segv1 PoC) that encodes a glyph with a corrupted advanceX metric, causing stbtt_GetCodepointHMetrics() to return a large negative value when parsed by raylib.
2. Gain local access: Obtain low-privileged local access to a system running an application built with a vulnerable version of raylib (up to commit 909f040).
3. Trigger font loading: Supply the malicious font file as input to the target application — for example, by placing it in a directory the application reads fonts from, or by passing it as a command-line argument to a font-loading harness.
4. Trigger integer overflow: When LoadFontData() processes the malicious glyph, the negative advanceX value is multiplied by fontSize and passed to RL_CALLOC, causing a calloc parameter overflow.
5. Achieve crash or memory corruption: In a release build, the invalid allocation propagates to GenImageFontAtlas(), which dereferences an invalid pointer, resulting in a SIGSEGV. Depending on heap layout and application context, further memory corruption effects may be achievable (GitHub Issue, GitHub PoC).

• File System: Presence of unexpected or externally supplied font files (e.g., .ttf, .otf) in application directories, particularly files with anomalous sizes or structures.
• Process: Application process (linked against raylib) terminating with SIGSEGV or SIGABRT; crash dumps referencing GenImageFontAtlas or LoadFontData in the stack trace.
• Logs: AddressSanitizer output containing calloc parameters overflow: count * size with negative values, referencing rtext.c:747; GDB backtraces showing #0 GenImageFontAtlas() at crash.
• File System: Presence of the known PoC file segv1 (SHA not publicly confirmed) from the repository github.com/oneafter/1224 on the local system (GitHub Issue, GitHub PoC).

Update raylib to a version that includes commit 5a3391fdce046bc5473e52afbd835dd2dc127146 (merged January 1, 2026), which adds bounds checking and negative value clamping in LoadFontData() and GenImageFontAtlas(). As a workaround, restrict local user access to systems running vulnerable raylib-based applications and implement input validation to reject untrusted or externally sourced font files before passing them to raylib. Downstream distributors such as openSUSE have also released security updates incorporating this fix (GitHub Commit, openSUSE Announce).

The vulnerability was reported by researcher "oneafter" via the raylib GitHub issue tracker on December 24, 2025, and the maintainer (raysan5) merged the fix within one week, acknowledging the contribution. The fix was part of a broader PR (#5450) addressing multiple related font-loading security issues (#5433, #5434, #5436). No significant broader media coverage or notable community controversy has been observed beyond the GitHub discussion (GitHub PR, GitHub Issue).