CVE-2025-15533: 
NixOS vulnerability analysis and mitigation

CVE-2025-15533 is a heap-based buffer overflow vulnerability in the GenImageFontAtlas() function within src/rtext.c of raysan5's raylib, affecting all versions up to and including commit 909f040. 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. It carries a CVSS v3.1 base score of 7.8 (High) per NVD, while the CNA (VulDB) rates it 5.3 (Medium) (GitHub Issue, Feedly).

The root cause is improper bounds checking (CWE-119, CWE-122) during pixel-copying operations in GenImageFontAtlas(). When building a font atlas image, the function iterates over packed glyphs and writes pixel data into a heap-allocated buffer; the calculated destination index can exceed the pre-allocated buffer size, resulting in an out-of-bounds write of 1 byte (or more) past the end of the allocation. The fix (commit 5a3391f) adds explicit bounds checks (destX >= 0 && destX < atlas.width && destY >= 0 && destY < atlas.height) before each write, and also guards against negative advanceX values that could cause integer overflow during allocation. Exploitation requires local access with low privileges and is triggered by supplying a crafted font file to a raylib-based application (GitHub Issue, GitHub Commit).

Successful exploitation can result in heap memory corruption, which may lead to information disclosure (reading adjacent heap contents), data integrity compromise, or application crash (denial of service). Because the overflow is a write primitive, there is a theoretical potential for code execution in scenarios where heap layout can be controlled, though practical exploitation for code execution would be complex. The scope is limited to the local system running a vulnerable raylib-based application, with no lateral movement potential beyond the affected process (Feedly, GitHub Issue).

A public proof-of-concept exploit (a crafted font file hbf2) is available on GitHub and was submitted alongside the vulnerability report (PoC). The CVSS v4.0 exploit maturity is rated PROOF_OF_CONCEPT. 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), indicating a very low probability of exploitation in the near term (Feedly).

1. Craft a malicious font file: Create or obtain a specially crafted font file (e.g., a TTF/OTF with glyph metrics designed to produce out-of-bounds offsets when packed into a font atlas). The public PoC file hbf2 from the reporter's repository can be used directly.
2. Identify a vulnerable target: Locate a system running a raylib-based application compiled against raylib at or before commit 909f040 that accepts or processes font files.
3. Deliver the font file: Supply the crafted font file as input to the target application — for example, by placing it in a directory the application reads from, or passing it as a command-line argument to a font-loading harness.
4. Trigger GenImageFontAtlas(): Cause the application to call GenImageFontAtlas() with the malicious glyph data, which triggers the out-of-bounds write at src/rtext.c:901.
5. Observe impact: Depending on heap layout, the result may be an application crash (DoS), heap metadata corruption, or potential for further memory exploitation. ASAN-instrumented builds will abort with a heap-buffer-overflow report (GitHub Issue, PoC).

• Process: Application crash or abnormal termination of a raylib-based process, particularly during font loading or atlas generation operations.
• Logs: AddressSanitizer output containing heap-buffer-overflow at src/rtext.c:901 in GenImageFontAtlas; crash dumps referencing rtext.c stack frames.
• File System: Presence of unexpected or malformed font files (e.g., TTF/OTF files with anomalous glyph metric values) in directories accessed by raylib applications; presence of the known PoC file hbf2.
• Process: Unexpected child processes or signal handlers triggered by a raylib application (e.g., SIGABRT, SIGSEGV) during font atlas generation (GitHub Issue).

Apply the security patch commit 5a3391fdce046bc5473e52afbd835dd2dc127146, which was merged into the raylib master branch on January 1, 2026 (any version beyond commit 909f040 containing this fix is safe). No official workaround short of patching is available; however, restricting local system access to trusted users and avoiding processing untrusted font files with vulnerable raylib builds reduces exposure. Downstream distributors such as SUSE and Red Hat have also tracked this issue for their packages (GitHub Commit, GitHub PR, Feedly).

The vulnerability was reported by researcher "oneafter" via a GitHub issue on December 24, 2025, and the raylib maintainer (raysan5) acknowledged and merged the fix within one week. The fix was part of a broader PR addressing multiple security vulnerabilities in the font loading module (issues #5433, #5434, #5436). Community reaction has been minimal given the local-only attack vector and low EPSS score; the issue was tracked by Red Hat and SUSE for their downstream packages (GitHub PR, GitHub Issue).