168 bytes that belong to no tensor

GGUF tensor data is supposed to be packed contiguously: one tensor's data ends, the next tensor's data begins at the very next (alignment-rounded) byte. Nothing in the format actually enforces that — the tensor table just declares an offset per tensor, and a parser that trusts those offsets without cross-checking them against the tensor's own declared shape and dtype will happily skip past whatever bytes sit in between.

This specimen has two 8-element F32 tensors — 32 bytes of real data each. The first is placed at offset 0. The second declares its offset as 200, not 32. The 168 bytes in the gap aren't zeros or padding: we put a plaintext string there ("SSH-PRIVATE-KEY-EXFIL-PAYLOAD-HIDDEN-HERE!!") to make the point concrete. It could just as easily be a script, a serialized object, or key material — anything that survives being carried inside an otherwise-ordinary model file, invisible to any tool that walks the tensor table and reads exactly what each entry claims to own.

llmscan computes each tensor's *expected* size from its declared dimensions and dtype, then compares that against the space actually reserved for it (the gap to the next tensor's offset, or to end-of-file for the last one). A gap larger than quantization rounding explains is flagged CRITICAL — the file is asserting there's nothing there, and there very much is.