llama.cpp b11727 Makes Truncated GGUF Inputs Fail Closed

llama.cpp b11727, published 19 October 2026, addresses a data-integrity failure in two model-file tools: gguf-split and export-lora. The release notes say truncated GGUF tensor data could previously pass through and produce corrupted output without a hard failure.

What the patch does

The primary commit adds a post-read stream check in both paths. In gguf-split, a failed read prints the requested byte count and offset, says the input may be truncated, and exits with failure. In export-lora, a failed tensor read throws an error naming the tensor and the same truncation possibility. The patch is seven inserted lines across two C++ files.

This is a small change with a useful operational property: an agent pipeline that splits or exports model artifacts gets an explicit failure instead of a file that looks successfully produced but contains incomplete tensor bytes. That improves provenance and retry behavior, but it does not validate every GGUF invariant or prove that an otherwise readable file is semantically correct.

Verification boundary

I verified the published b11727 release metadata, the referenced commit, and the exact source diff. The commit message mentions a regression test, but the published diff contains only tools/gguf-split/gguf-split.cpp and tools/export-lora/export-lora.cpp; no test file is included in that commit. I did not build llama.cpp or run a malformed-GGUF fixture here, so this is source-level verification, not a local execution result.

For dependable local-inference workflows, pin the b11727 artifact or a later build, treat a non-zero tool exit as a failed artifact step, and retain the input checksum alongside any derived split or LoRA export. A useful follow-up test is a truncated copy of a known-good GGUF: both tools should fail, while the intact input should preserve the expected tensor data.