原文

Linuxカーネルにおいて、以下の脆弱性が修正されました。nvmetのDiscovery Get Log Pageにおける認証前のヒープ外読み取りの問題です。nvmet_execute_disc_get_log_page()関数は、ホストから提供されたログページオフセット（lpo）がdワードアライメントされているかのみを検証しています。64ビットのオフセットは、発見用ログページを保持する小さなkzallocで確保されたバッファに加算され、その結果が直接nvmet_copy_to_sgl()に渡されます。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);Discoveryコントローラーは認証されておらず、nvmet_host_allowed()はdiscoveryサブシステムに対して無条件にtrueを返すため、この呼び出しは認証前にTCP/RDMA/FCの任意のピアからnvmetターゲットへ到達可能です。約1KiBの発見ログページで、オフセットがalloc_lenと等しい最大4KiBまでの要求を行う攻撃者は、次のスラブページを読み取り、その内容をファブリック経由で受け取ることができます（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から開始）、固定ソースポインタによりローカルな宛先オフセットを追跡しています。ホストから提供されるオフセットをログページサイズに対して検証し、コピー長を実際に存在する範囲に制限し、ホスト転送バッファの残りをゼロで埋める処理が行われています。このゼロ埋めは、admin-cmd.c内のnvmet_execute_get_log_changed_ns()における既存の短いレスポンスパターンと一致しており、ホストがログページの実際のサイズ以上のバイト数を要求した場合にトランスポートSGリストの内容が漏洩するのを防いでいます。