A metadata field that lies about its own size

GGUF metadata strings are length-prefixed: an 8-byte length field, then that many bytes of UTF-8 text. A correct parser reads the length, then reads exactly that many bytes. We built a file where the length field for general.architecture claims 65,535 bytes, but only 5 actual bytes ("llama") follow it before the file ends.

This is not an abstract concern — it's the exact failure mode behind CVE-2024-23496 (CVSS 9.8), a real, disclosed heap buffer overflow in llama.cpp's gguf_fread_str function. That code trusted the declared length to size a read/allocation without validating it against the bytes actually available, and a crafted GGUF file could use it to corrupt heap memory and potentially achieve code execution on whatever machine loaded the file.

To be precise about what this specimen demonstrates: it reproduces the malformed *input* that triggers that bug class, not the memory corruption itself — reproducing an actual heap overflow requires the vulnerable C parser, not a Python scanner. What we can show, and do show, is that llmscan's own reader treats an unsatisfiable length claim as untrustworthy input and stops cleanly instead of reading past the end of the buffer, flagging it as a parse failure rather than silently accepting whatever garbage the length field points at.