llama.cpp b10451、LoRAテンソルにファイル境界チェックを追加——切り詰められた重みの暗黙的なゼロ埋めを防止

llama.cppの8月16日付b10451ビルドでは、モデル品質の問題と誤認されやすいLoRA読み込み処理の不備が修正された。メインモデルのローダーは以前から各テンソルのデータ範囲をチェックしていたが、adapterの読み込みパスは、GGUFに記録されたoffsetとtensor sizeに基づいて直接データを読み込み、その合計が実際のファイル範囲内に収まっているかを確認していなかった。また、テンソル名の検索に失敗した場合も、インデックスの有効性を事前に検証していなかった。[マージ時の説明](https://github.com/ggml-org/llama.cpp/pull/27056)によると、このため、切り詰められた、または破損したLoRAが暗黙的に読み込まれ、不足しているバイトがゼロで埋められても、プログラムがエラーを報告しない可能性があった。

修正後のLoRA読み込みパスでは、メインモデルのローダーと同じbounds checkを使用し、tensor indexも検証する。メンテナーはデータセクションを切り詰めたadapterでテストを実施し、新版が「tensor data is not within the file bounds」を返す一方、有効なファイルは従来どおり正常に読み込まれることを確認した。これは新しい量子化手法でも推論高速化でもないが、可観測性を直接改善する。同じadapterでも、ダウンロード、キャッシュ同期、ファイル配布の過程で一部しか取得できなかった場合、旧版では実行可能でありながら挙動がずれたモデルが生成され、チームが原因をプロンプト、ベースモデル、またはファインチューニング自体に誤って帰属させるおそれがあった。

影響が生じる背景には、GGUFがmetadataとtensorsを同じファイルに格納する形式であることがある。[Hugging FaceのGGUFドキュメント](https://huggingface.co/docs/hub/gguf)でも、Hubにはテンソル名、形状、精度が表示されると説明されているが、metadataを解析できることは、後続するすべてのtensor bytesが完全であることを意味しない。複数のコミュニティ製LoRAを動的にマウントするローカルサービスは、b10451を含むビルドへアップグレードし、ダウンロード層でハッシュを保存するかrevisionを固定すべきだ。なお、プロジェクトはこの修正をCVEとして指定しておらず、任意コード実行につながることを示す証拠もない。現時点で確認されているリスクは、重みの暗黙的な破損と誤った推論である。今後は、ほかのGGUF adapter、control vector、分割ファイルの読み込みパスでも、一貫した範囲検証が採用されるか注視する必要がある。