gguf-t5-precompiled-charsmap-strlen-oob-poc

GGUF T5 precompiled charsmap strlen() OOB read PoC

This repository proves a narrow claim: loading a crafted T5 GGUF and tokenizing a matching prompt prefix triggers a heap-buffer-overflow in llama.cpp because strlen() is called on an unterminated replacement string from tokenizer.ggml.precompiled_charsmap.

• What this PoC shows:

  • the attacker controls a GGUF tokenizer metadata blob
  • the model loads through the normal vocab path
  • tokenizing the prompt "A" triggers an out-of-bounds heap read in native code

• What this PoC does not show:

  • code execution
  • arbitrary file read or write
  • a bug affecting every GGUF tokenizer type

• Verified commit:

  • 95e5254c0ae93529b2f6c05e210b9cac5c0070fc

Files

• build_malicious_t5_charsmap_strlen.py: helper to generate t5-precompiled-charsmap-strlen-oob.gguf
• poc_vocab_tokenize_loader.cpp: minimal vocab-loading and tokenization harness using product code
• build_stubs.cpp: small helper stubs needed by the reduced harness build

Scope

The crafted metadata blob encodes a valid XCDA leaf for the byte A and a replacement offset that points to the last byte of the attacker-controlled prefix-replacement region without a NUL terminator. The tokenizer later calls strlen() on that pointer while normalizing "A".

Reproduce

First generate t5-precompiled-charsmap-strlen-oob.gguf with build_malicious_t5_charsmap_strlen.py. Then build a small ASAN/UBSAN-instrumented loader from product sources together with poc_vocab_tokenize_loader.cpp and build_stubs.cpp, and run:

ASAN_OPTIONS=detect_leaks=0 \
./poc_vocab_tokenize_loader ./t5-precompiled-charsmap-strlen-oob.gguf

The expected result is an AddressSanitizer report showing:

• ERROR: AddressSanitizer: heap-buffer-overflow
• READ of size 2
• a stack including strlen
• a stack including llm_tokenizer_ugm_session::normalize_prefix