A tensor dimension built to overflow

We patched a single u64 field in the tensor info table — blk.0.attn_k.weight's first dimension — from 8 to 2,000,000,000, leaving the actual tensor data untouched. Nothing about the file size or the surrounding header changed.

This is a known class of GGUF parser attack: element counts computed from attacker-controlled dimension fields, multiplied together to size a buffer, with no sanity check against the file's actual size. Depending on the runtime, this produces anything from an out-of-memory abort to a heap buffer sized far smaller than the loader assumes.

The engine catches it structurally, without ever allocating that buffer: dimension values are checked against a realistic ceiling before anything downstream trusts them. It also flags the resulting implausible bits-per-parameter ratio as a second, independent signal.

That second signal is worth calling out on its own: the scanner is comparing what the file claims (declared parameter count) against what it actually is (bytes on disk), and flagging the gap as a resource-exhaustion risk before anything is loaded. That's the same family of bug as CVE-2026-54233 in vLLM — a small compressed upload that decoded to ~14.9GB of PCM data because nothing checked the *decoded* size against a sane limit. Different surface (a model file's tensor metadata vs. an inference server's audio endpoint), same underlying failure: trusting a declared or compressed size instead of verifying what it expands to.