CVE-2026-64320 in Linux
要約
〜によって VulDB • 2026年07月25日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
nvmet: Discovery Get Log Pageにおける認証前のヒープ外読み込みを修正
`nvmet_execute_disc_get_log_page()`関数は、ホストから提供されるLog Page Offset (lpo)のdwordアラインメントのみを検証しています。64ビットオフセットは、ディスカバリログページを保持する小さなkzalloc割り当てバッファに追加され、その結果が`nvmet_copy_to_sgl()`へそのまま渡されます。この関数はソース側の境界チェックを行わず、`data_len`バイト分のデータをホストに対して`memcpy()`でコピーします：
u64 offset = nvmet_get_log_page_offset(req->cmd); /* 64ビット ホスト */ size_t data_len = nvmet_get_log_page_len(req->cmd); /* 32ビット ホスト */ ... if (offset & 0x3) { ... } /* 唯一のチェック */
... alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req); buffer = kzalloc(alloc_len, GFP_KERNEL); ... status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);
ディスカバリコントローラは認証不要です。`nvmet_host_allowed()`関数は、discoveryサブシステムに対して無条件にtrueを返すため、この呼び出しは任意のTCP/RDMA/FCピアから、nvmetターゲットへ到達可能な状態であれば認証前に実行可能です。約1 KiBのディスカバリログページに対し、攻撃者がオフセット `== alloc_len` から最大4 KiBまでのデータを要求すると、次のスラブページの外部を読み込み、その内容がファブリック経由で返されます（デフォルト設定のnvmet-tcpループバックターゲットでの実証実験では、1回のGet Log Pageレスポンス内で81個の正規化されたカーネルポインタが漏洩しました）。オフセットを未マップのカーネルメモリに向けると、インカーネル内の`memcpy()`でフォールトが発生し、ターゲットホストはクラッシュします（または `panic_on_oops=1` の場合パニックします）。
攻撃者が制御可能なソース側のオフセットパターン "nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" は、nvmetコードベース全体で`nvmet_execute_disc_get_log_page()`固有のものです。admin-cmd.c内の他のすべてのGet Log Pageハンドラは、lpoを無視して（応答をオフセット0から開始する）、または固定されたソースポインタに対してローカルの宛先オフセットを追跡しています。
ホストから提供されるオフセットをログページのサイズで検証し、コピー長を実際に利用可能な範囲に制限します。また、ホストの転送バッファに残りの領域がある場合はゼロ埋めを行います。このゼロ埋めは`nvmet_execute_get_log_changed_ns()`（admin-cmd.c）における既存の短縮応答パターンと一致しており、ログページに含まれるバイト数よりも多くのデータを要求された場合に、トランスポートSGLの内容が漏洩するのを防ぎます。
If you want to get best quality of vulnerability data, you may have to visit VulDB.