Discussion on "Your Model File Is Untrusted Input"

Harrison Guo · 2026-09-20T16:41:17.253Z

Sixty-five bytes is not a model. It is not even a header with something plausible after it. It is a GGUF magic number, a few counts, and a tensor whose second dimension is zero. Load it and llama.cpp

Discussion on "Your Model File Is Untrusted Input" | Hashnode

Harrison Guo

Sep 20

"Friendly version" is right. A divide by zero fails close to the trust boundary, where the cause is still visible. An unchecked count reused as a size can fail much farther downstream—as an overflow, an oversized allocation, or a bad shape—with a much less useful error.

Pickle got scrutiny because the exploit was easy to demonstrate. GGUF feels inert because it contains tensors rather than executable code, but its header values still feed a C++ parser. The validator therefore has to check what the downstream code requires, not merely what the format allows.

Harrison Guo

Oct 5

You've extended it to exactly the right place. The 'inert' framing is where people get lulled: there's no executable content, so it feels safe, but the parser is doing arithmetic on attacker-controlled counts, sizes and offsets before it validates any of them. A lie in a tensor count or a dimension becomes a multiply that overflows, an allocation that's too small, a loop that walks off the end, and as you say the same shape shows up in fonts, images, any format a fast parser consumes. That's the concrete form of 'check what the consumer requires': validate that each count and offset is consistent with what the loader will actually do with it, the allocation it implies and the bytes it will read, not merely that the header is well-formed. Spec-conformant is a promise about the file; survivable is a promise about the consumer, and only the second one closes these.

AÖ

Ahmet Özel

AI Engineer. Computer Vision, RAG and LLM agents.

Oct 6

That consumer-level invariant is the part I would encode in the test corpus. For each tensor, the checked product of dimensions, byte size and offset range should agree before allocation or pointer traversal; checking each dimension in isolation does not establish that agreement.

The legitimate empty-tensor case also deserves its own fixture so a defensive patch cannot simply reject everything with a zero. Running malformed and valid boundary cases under sanitizers would test the arithmetic and the consuming path together, rather than only testing that the header parser returns an error.

Mihai_LeanZero

Atlassian consultant and Forge developer at LeanZero. We do Data Center to Cloud migrations and build Forge apps, and I write up what I learn at leanzero.net.

Sep 20

The ne[j] >= 0 line is the best part of this writeup. It's correct, it passed review, and it's still the reason the crash below it went unquestioned for as long as it did. I run into the same shape reviewing agent output before it gets applied to anything real - a schema-valid check that reads as "this is safe" when the code underneath assumed something narrower than schema-valid ever guaranteed. Collapsing the per-dimension checks into ggml_nelements(info.t) > 0 is the same move as replacing three guard clauses with the one statement that actually says what the invariant was. The diffusion zero-tensor correction is the part I'd have gotten wrong too - rejecting zero outright is the obvious fix and it's the wrong one.

Harrison Guo

Sep 20

That agent-output parallel is useful. ne[j] >= 0 correctly answers "is this dimension negative?" The downstream code needed the answer to a different question: "does this tensor contain anything?" Because both look like dimension validation, a reviewer sees the first check and moves on.

Rejecting zero everywhere would also be wrong; legitimate zero-length tensors exist. The fix is to enforce non-emptiness at the path that requires it. Here, ggml_nelements(info.t) > 0 states the assumption the allocation path was already making.

"The validator has to check what the downstream code requires, not merely what the format allows" is the line I would take away, and it names why format-level validation keeps disappointing people. A spec-conformant file is a much weaker guarantee than a file the consumer can survive, and the gap between those two is exactly where these bugs live.

The inert-looking part matters too. A .gguf holds tensors rather than code, so it reads as data in a way a pickle never did, and that intuition is precisely what stops anyone asking who parses it.

The same reasoning covers any binary artifact a fast parser consumes — fonts, images, model files — where the danger is not executable content but the arithmetic done on attacker-controlled counts before anything gets validated.

Search Hashnode

Your Model File Is Untrusted Input

Responses7