llama.cpp b11393: 閉じたツール呼び出しをパーサー状態に残さない

ツール呼び出しを閉じるなら、メモリ上の参照も終える

llama.cpp b11393 は 2026年10月4日に公開されたプリリリースです。関連する pull request #29942 は UTC 10:12 に作成され、UTC 15:59 にマージされました。対象は chat-PEG パーサーであり、JSON Schema 出力全般やツール実行の認可全般ではありません。

この pull request が説明するのは状態の寿命の不整合です。TOOL_CLOSE が保留中のツール呼び出しをリセットした後も、current_tool は破棄済みのオブジェクトを指していました。その後に TOOL_ID が来ると、この古い参照を通じて処理される可能性があります。マージされた commit dbe4c3e は、保留中の呼び出しをリセットする時点で current_tool を消します。作者は、識別子の割当サイズクラスが異なる条件での use-after-free と double-free、および回帰ケースの追加を報告しています。ただし、ここで確認した commit の変更ファイル一覧にはパーサー修正しかなく、報告されたテストがマージされたことは裏付けません。これらは作者の報告であり、独立再現済みのセキュリティ評価、CVE、全パーサーへの保証ではありません。

1. 1TOOL_OPEN
2. 2保留中のツール呼び出しと current_tool
3. 3TOOL_CLOSE
4. 4完了した呼び出しを複製

1. 1TOOL_CLOSE
2. 2保留中の呼び出しをリセット
3. 3current_tool を消去
4. 4後続の TOOL_ID に有効な対象はない

1. 1この順序を表せないパーサーやテンプレート
2. 2この根拠の対象外

現行の server README は関数呼び出しと tool use をサーバー機能として説明しますが、パーサー修正を権限制御に変えるものではありません。ツール呼び出しの形が正しいことと、アプリケーションがその操作を許すこと、保持する認証情報、待受先へ到達できることは別です。リポジトリの MIT ライセンスはコードの条件です。モデル重み、ツール、プロンプト、デプロイデータには個別の条件があります。security policy も、モデルを安全に隔離できない場合には信頼できないネットワークでサーバー機能を使わないよう注意しています。

2024年から現行 mapper までの具体的な経路

PR #9639 は 2024年9月25日に作成され、2025年1月30日にマージされました。汎用とモデル固有のツール呼び出しのパースをサーバーへ導入した変更です。2026年3月6日にマージされた PR #18675 は、PEG パーサーとテンプレート解析を中心に構成を改めました。この経路を追うと、試験記録にテンプレートとパーサー revision が必要な理由が分かります。同じリクエストだけでは実装経路を特定できません。これらの変更は、全モデルが同じ文法を使うことや、b11393 が古い下流 UI の問題まで解決することを示しません。

文法経路を固定してから、禁止したい遷移を調べる

b11393 は評価候補であって、ローカルのエンドポイントを無条件に更新する理由ではありません。release tag、解決した commit、プラットフォーム用アーティファクトのチェックサム、モデル revision、chat template、parser の選択、リクエストバイト列、待受範囲を記録します。ツール呼び出しが一度成功しただけの試験では、この修正が扱う状態遷移を観測できません。

以下は一つのローカル利用者だけを対象にした、未実行の N=1 フィクスチャです。

1. 隔離した loopback 専用の環境で、固定した b11393 build と一つの parser/template 組み合わせを使います。ツールにファイルシステム、ブラウザー、ネットワーク、認証情報へのアクセスを渡しません。
2. TOOL_OPEN、識別子 A、TOOL_CLOSE、識別子 B の順に並ぶ最小の parser fixture を投入します。モデルが生成するコマンドではなく、パーサー試験用の入力として扱います。固定した timeout の範囲で、exit status、parser diagnostic、build identity、経過時間を保存します。
3. 合格条件は限定的です。プロセスが健全なまま、閉じた呼び出しに後続の識別子が付かないことです。クラッシュ、sanitizer の報告、想定外の付加、timeout、異なる parser identity は不合格です。記録を残し、入力を変える前にこの一つの境界を調べます。

このフィクスチャが記述するのは状態の契約です。割当サイズクラスを指定していないため、作者のメモリ障害の再現条件にはなりません。実装前に固定した版の common/chat-peg-parser.cpp の mapper と tests/test-chat-peg-parser.cpp の試験枠組みを読み、その版で実在するパーサー規則にイベントを対応させます。ここでの TOOL_OPEN や TOOL_ID は内部イベント名であり、リクエストのフィールドやモデルへ渡す文字列ではありません。各イベントについて、位置、保留中の呼び出しの有無、有効な current-tool 参照の有無、完了済み呼び出しの識別子を一行ずつ残します。最後の行では完了済み呼び出しの A を保持し、B には閉じた呼び出しを対象として与えません。選んだ文法がこの順序を表せない場合は未対応の入力として記録し、合格にはしません。

失敗時に別の runtime、制約のない parser、自動 retry、ツール実行へ切り替えてはいけません。このフィクスチャは、悪用可能性、リモートからの到達可能性、モデルの挙動、スループット、template 全体のメモリ安全性、マルチテナントサービスの安全性を測りません。本稿の作成時にはダウンロード、build、parser 実行、チェックサム確認、sanitizer 実行、ベンチマークを行っていません。これらの作業にはローカル計算資源、ストレージ、運用者の時間がかかります。

Schema 制約付き出力とは別の問題である理由

先の schema-boundary の記事 は Ling 3.0 の response-format grammar 経路を扱いました。b11393 の根拠は、chat-PEG のツール呼び出しオブジェクトが close marker の後にどう寿命を終えるかを追います。どちらも parser を固定して一つの利用者の契約を検証する考え方ですが、結果を別の parser 系へ移すことはできません。実際の操作を呼ぶアプリケーションでは、パースの後にも独立した認可判断を置きます。パーサーの受理は構文と状態処理を示すだけです。