GGUF T5 precompiled charsmap OOB read PoC

This repository proves a narrow claim: loading a crafted T5 GGUF whose tokenizer.ggml.precompiled_charsmap metadata is only 1 byte long triggers a heap-buffer-overflow during tokenizer initialization in llama.cpp.

• What this PoC shows:

- the attacker controls a GGUF metadata field

- the native loader reads 4 bytes from a 1-byte heap buffer

- the fault happens during model load, before inference

• What this PoC does not show:

- code execution

- arbitrary file read or write

- a broader bug affecting every GGUF tokenizer type

• Verified commit:

- 95e5254c0ae93529b2f6c05e210b9cac5c0070fc

Files

• build_malicious_t5_charsmap.py: helper to generate t5-precompiled-charsmap-oob.gguf from a local llama.cpp checkout
• poc_vocab_only_loader.cpp: minimal vocab-loading harness using product code
• build_stubs.cpp: small helper stubs needed by the reduced harness build

Generate the malicious GGUF

python3 build_malicious_t5_charsmap.py /path/to/llama.cpp ./t5-precompiled-charsmap-oob.gguf

That helper imports gguf-py from the provided llama.cpp checkout and therefore expects its Python dependencies to be available. It writes a GGUF with:

• general.architecture = "t5"
• tokenizer.ggml.model = "t5"
• tokenizer.ggml.precompiled_charsmap = b"\\x41"

Reproduce

First generate t5-precompiled-charsmap-oob.gguf with the helper above. Then build a small ASAN-instrumented loader from product sources together with poc_vocab_only_loader.cpp and build_stubs.cpp, and run it against t5-precompiled-charsmap-oob.gguf.

The expected result is an AddressSanitizer report showing:

• ERROR: AddressSanitizer: heap-buffer-overflow
• READ of size 4
• a stack including llm_tokenizer_ugm::llm_tokenizer_ugm