CVE-2025-15533
Heap-Based Buffer Overflow in raylib GenImageFontAtlas Function
Publication date: 2026-01-18
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| raylib | raylib | to 2026-01-01 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-119 | The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data. |
| CWE-122 | A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc(). |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-15533 is a heap-based buffer overflow vulnerability in the Raylib library, specifically in the function GenImageFontAtlas within the src/rtext.c file. The vulnerability occurs when the function writes pixel data beyond the allocated heap buffer boundary for the font atlas image, either by writing a few bytes past the buffer end (heap overflow) or writing before the buffer start (heap underflow). This happens due to incorrect bounds checking and packing logic when copying glyph image data into the font atlas bitmap. Malicious font files with crafted glyph metrics can trigger this overflow, potentially causing memory corruption or application crashes. The issue is local and requires local access to exploit. A patch has been released to fix the problem by validating glyph metrics, preventing negative or zero allocations, and enforcing strict bounds checking during image data manipulation. [1, 4, 5, 7]
How can this vulnerability impact me? :
This vulnerability can impact you by causing memory corruption in applications using the Raylib library's font loading functionality. Exploiting the heap-based buffer overflow can lead to application crashes, denial of service, or potentially allow an attacker with local access to execute arbitrary code or escalate privileges. Since the overflow occurs during font atlas generation, malicious font files can be used to trigger these effects. The vulnerability affects the confidentiality, integrity, and availability of the system where the vulnerable Raylib version is used. Applying the provided patch is advised to mitigate these risks. [4, 5, 6, 7]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by compiling the Raylib font test harness with AddressSanitizer enabled and running it with a fuzzing input that triggers the heap-buffer-overflow or heap underflow. Specifically, compile with flags like `-fsanitize=address -g` using Clang on a Linux x86_64 environment. Running the test harness with the provided repro input will reproduce the invalid memory write, which AddressSanitizer will report. This method detects the vulnerability locally during testing or development. Example commands include: `clang -fsanitize=address -g -o font_test_harness font_test_harness.c` followed by `./font_test_harness <fuzz_input>` to trigger the overflow and observe ASAN reports. [4, 5, 7]
What immediate steps should I take to mitigate this vulnerability?
The immediate step to mitigate this vulnerability is to apply the patch identified by commit `5a3391fdce046bc5473e52afbd835dd2dc127146` in the Raylib GitHub repository. This patch includes fixes such as preventing negative advance width values, conditional memory allocation, bounds checking on atlas data writes, and safe addition of white rectangles in the font atlas. Applying this patch will prevent heap-based buffer overflows and underflows in the `GenImageFontAtlas` function. Additionally, avoid using untrusted or malicious font files locally until the patch is applied. [1, 3, 6, 7]