llama.cpp GGUF loader accepts tensors whose padded size wraps to zero

The GGUF loader used by llama.cpp can treat a malformed model file as valid when a tensor's padded byte count wraps to zero, so the runtime under-reports how much data the file actually claims.

While reading tensors, the loader rounds each tensor's raw size up to the format's alignment, then adds that padded value into a running total and rejects anything that would overflow the total. The padding step is unsafe: if the raw size sits within a few bytes of the maximum value a size_t can hold, adding the alignment constant wraps on 64-bit arithmetic and the masked result becomes zero. The overflow guard only sees that zero, so it always passes. Earlier tensors still contribute their real sizes; the oversized one does not. The tensor object is still created with its full declared shape and a data pointer into the short backing buffer.

Anything that trusts the loader's aggregate size, or that iterates a tensor by its own dimensions, can therefore work from inconsistent metadata. The weak check lives in the shared GGUF parsing path used by the core library and has been present for a long time. The report includes a fix that rejects the wrap before the padded size is accepted.