llamacpp-swa-blockcount-oob-poc

PoC — llama.cpp GGUF block_count → is_swa_impl[512] heap out-of-bounds write

huntr Model File Vulnerabilities PoC against ggml-org/llama.cpp @ 2d97363. Authorized security research (responsible disclosure via huntr).

Bug

llama_hparams::set_swa_pattern (src/llama-hparams.cpp:8) loops for (il = n_layer(); il < n_layer_all; ++il) is_swa_impl[il] = false; where is_swa_impl is a fixed std::array<uint32_t, 512> (LLAMA_MAX_LAYERS, llama-hparams.h:150) and n_layer_all is the GGUF block_count (LLM_KV_BLOCK_COUNT, llama-model.cpp:1060), read with no upper bound. A malicious GGUF with block_count > 512 writes past the array — a contiguous heap OOB write of length block_count, at model-load time (no inference needed), for SWA-pattern archs (gemma3, cohere2, olmo2, phi3, …).

Files

• swa_repro.cpp / CRASH_PROVEN.md — isolated repro; EXC_BAD_ACCESS (write) at the set_swa_pattern store.
• gen_gguf_blockcount.py / poc_swa_blockcount.gguf — malicious gemma3 GGUF (block_count=100,000,000).

Reproduce

c++ -O0 -g swa_repro.cpp -o swa_repro && ./swa_repro 100000000   # -> EXC_BAD_ACCESS at set_swa_pattern
# end-to-end:
llama-cli -m poc_swa_blockcount.gguf -p hi                        # crashes in set_swa_pattern during load

(See CRASH_PROVEN.md for the -O0 note: the isolated array is never read so -O2 would dead-store-eliminate; the real llama.cpp reads is_swa_impl later, so the writes are live in a normal Release build.)

Fix

Validate block_count / n_layer_all against LLAMA_MAX_LAYERS unconditionally before use.