本機推論／模型完整性
llama.cpp b10451 Adds File-Bounds Checks for LoRA Tensors, So Truncated Weights Are No Longer Silently Zero-Filled
The previous LoRA loading path did not verify whether a tensor’s offset plus its size exceeded the GGUF file bounds, allowing corrupted or incompletely downloaded adapters to appear to load successfully. b10451 now fails immediately and confirms that the tensor index actually exists.
The August 16 b10451 build of llama.cpp fixes a gap in LoRA loading that could easily be mistaken for a model-quality issue. The main model loader already checked the data range of every tensor, but the adapter path read data directly using the offset and tensor size recorded in the GGUF file without verifying that their sum remained within the actual file bounds. It also failed to validate the tensor index before handling an unsuccessful tensor-name lookup. According to the [merge description](https://github.com/ggml-org/llama.cpp/pull/27056), this meant a truncated or corrupted LoRA could be loaded silently, with missing bytes zero-filled and no error reported.
After the fix, the LoRA path uses the same bounds check as the main model loader and also validates the tensor index. The maintainer tested the change with an adapter whose data section had been truncated: the new version returns “tensor data is not within the file bounds,” while valid files continue to load normally. This is neither a new quantization method nor an inference acceleration, but it directly improves observability. If an adapter is only partially retrieved during download, cache synchronization, or file distribution, older versions may produce a runnable model with altered behavior, leading teams to wrongly attribute the problem to the prompt, base model, or fine-tuning itself.
The impact stems from GGUF packaging both metadata and tensors. The [Hugging Face GGUF documentation](https://huggingface.co/docs/hub/gguf) also explains that the Hub displays tensor names, shapes, and precision, but successfully parsing the metadata does not guarantee that all subsequent tensor bytes are complete. Local services that dynamically mount multiple community LoRAs should upgrade to a build that includes b10451 and retain hashes or pin revisions at the download layer. It is important to note that the project has not designated this fix as a CVE, and there is no evidence that the issue enables arbitrary code execution. The currently confirmed risks are silent weight corruption and incorrect inference. It will be worth monitoring whether other GGUF adapter, control-vector, and sharded-loading paths adopt consistent bounds validation.