CVE-2026-64319は、Azure Linux 3.0のLinuxカーネルに含まれるNVMe over Fabricsの認証処理において、受信データの長さを適切に検証していなかった脆弱性です。CVSS基本値は9.1で、認証前の攻撃によってカーネルメモリの境界外読み取りが発生する可能性があります。
Azure Linux 3.0の標準kernelパッケージを利用している場合、MSRCが示す最初の修正版はazl3 kernel 6.6.144.1-1です。まずuname -rで稼働中のカーネルを確認し、該当する場合は修正版へ更新したうえで再起動してください。修正版をインストールしただけでは、古いカーネルが引き続き稼働している可能性があります。(Microsoft Security Response Center)
CVE-2026-64319の概要
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-64319 |
| 対象 | Microsoft Azure Linux 3.0 |
| 影響を受ける部分 | LinuxカーネルのNVMe-oFターゲット認証処理 |
| 関連ファイル | drivers/nvme/target/fabrics-cmd-auth.c |
| 問題の種類 | 認証応答に含まれる可変長データの境界検証不備 |
| CVSS 3.1 | 9.1 Critical |
| CVSSベクター | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H |
| CWE | MSRCおよび公開CVE情報では未掲載 |
| Azure Linux 3.0のFirstFixed | azl3 kernel 6.6.144.1-1 |
| 必要な対応 | カーネル更新、再起動、稼働バージョンの再確認 |
CVSSベクターは、ネットワーク経由で攻撃でき、攻撃難易度が低く、事前の権限や利用者操作を必要としないことを示しています。影響は機密性と可用性が「High」、整合性は「None」と評価されています。公開情報にCWEは設定されていないため、管理台帳へ独自判断でCWE-125などを記載する場合は、公式分類ではなく組織内の補助分類であることを明記した方が安全です。(NVD)
NVMe認証応答の境界検証不備とは
問題はNVMe-oFターゲット側の認証処理にある
CVE-2026-64319が存在するのは、Linuxカーネルのnvmet-auth、つまりNVMe over Fabricsのターゲット側で認証を処理する部分です。
NVMe over Fabricsは、NVMeストレージへネットワーク経由で接続するための仕組みです。ストレージを公開する側がターゲット、接続する側がイニシエーターと呼ばれます。
そのため、Azure VMにNVMe形式のローカルディスクや一時ディスクが接続されているだけで、直ちに外部から攻撃できるわけではありません。特に優先度が高いのは、Azure Linux 3.0をNVMe-oFターゲットとして構成し、認証付きでストレージを公開している環境です。
攻撃者が指定した長さを十分に確認していなかった
問題のあるnvmet_auth_reply()関数は、認証応答であるDHCHAP_REPLYメッセージを処理します。
このメッセージには、主に次のような長さ情報が含まれます。
tl：受信したデータ全体の転送長hl：ハッシュ値の長さdhvlen：Diffie-Hellman公開値の長さrval[]：認証応答などが格納される可変長領域
脆弱な処理では、hlとdhvlenが実際の転送長tlに収まっているかを十分に確認しないまま、rval[]内のデータを参照していました。
悪意あるイニシエーターが、実際の転送長を小さくしながらhlやdhvlenを大きく設定すると、割り当てられたヒープ領域の外側が読み取られる可能性があります。DH認証を設定した環境では、境界外のポインターが共有秘密計算へ渡され、最大526バイト先まで読み取られる可能性があると説明されています。しかも、この処理は認証完了前に到達できます。(NVD)
修正では、可変長領域へアクセスする前に、概念的に次の条件を満たすか確認する処理が追加されています。
sizeof(*data) + 2 * hl + dhvlen <= tlデータ構造本体、2つのハッシュ値、DH公開値の合計が転送長を超える場合は、認証ペイロードを不正として拒否します。
影響度を判断するポイント
Azure Linux 3.0がインストールされているかだけでなく、実際に攻撃経路が存在するかを確認すると、対応順序を決めやすくなります。
| 環境 | 実際のリスク | 推奨対応 |
|---|---|---|
| 修正版未満でNVMe-oFターゲットを外部または広いネットワークへ公開 | 非常に高い | 緊急で更新し、更新まで通信元を制限 |
| 修正版未満でNVMe-oFターゲットを閉域網へ公開 | 高い | 速やかに更新し、接続可能なイニシエーターを再確認 |
| NVMe-oFターゲット機能はあるが現在未使用 | 中程度 | 不要なターゲット設定を停止し、カーネルを更新 |
| NVMeローカルディスクを使うだけでターゲット機能は未使用 | 直接の攻撃経路は限定的 | 通常のセキュリティ更新計画で早期に更新 |
| 修正版をインストール済みだが再起動していない | 修正前カーネルが稼働中 | メンテナンス時間を確保して再起動 |
kernel-hweや独自カーネルを使用 | 標準kernelの判定基準を流用できない | 利用中のカーネル系列ごとに修正状況を確認 |
攻撃経路が見当たらないことは、更新不要を意味しません。ネットワーク構成やサービス設定が将来変更される可能性もあるため、脆弱なカーネルを長期間残さないことが重要です。
Azure Linux 3.0でカーネル版を確認する方法
OSの種類と稼働中のカーネルを確認する
最初に、対象ホストがAzure Linux 3.0であることと、現在稼働しているカーネルを確認します。
grep -E '^(NAME|VERSION|VERSION_ID)=' /etc/os-release
uname -r修正版が稼働している場合、標準カーネルでは次のような表示になります。
6.6.144.1-1.azl3.x86_64末尾の表記はアーキテクチャやビルドによって異なる場合があります。重要なのは、Azure Linux 3.0の標準kernelパッケージについて、MSRCが示す6.6.144.1-1以降の修正版が実際に起動していることです。
インストール済みカーネルを確認する
次のコマンドでは、インストール済みの標準カーネルを一覧表示できます。
rpm -q kernel --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n'カーネル関連パッケージ全体を確認する場合は、次のコマンドを使用します。
rpm -qa | grep -E '^kernel($|-)' | sort -V確認結果は次のように判断します。
| インストール済み | uname -rの結果 | 判断 |
|---|---|---|
| 修正版なし | 修正版未満 | 更新が必要 |
| 修正版あり | 修正版未満 | 更新済みだが再起動待ち |
| 修正版あり | 修正版 | 修正適用済み |
| 独自カーネル | 独自の版番号 | バージョン文字列だけでは判断不可 |
カーネルの種類を取り違えない
MSRCのFirstFixedであるazl3 kernel 6.6.144.1-1は、Azure Linux 3.0の標準kernelパッケージに対する情報です。
次のような別系列を利用している場合は、標準カーネルの版番号だけで安全と判断しないでください。
kernel-hwekernel-mshv- ベンダー独自カーネル
- 自社ビルドしたカーネル
- 固定されたコンテナー基盤用ノードイメージ
特に独自カーネルでは、表示される版番号が新しくても修正コミットが含まれていない場合や、逆に古い版番号へ修正だけがバックポートされている場合があります。
upstream LinuxとAzure Linuxの修正版が違って見える理由
公開CVE情報では、Linux 6.6系列の修正版としてupstreamの6.6.145が記載されています。一方、MSRCはAzure Linux 3.0の最初の修正版を6.6.144.1-1としています。(NVD)
これは矛盾ではありません。
Linuxディストリビューションは、upstreamの修正を既存カーネルへバックポートすることがあります。そのため、Azure Linuxの6.6.144.1-1は、ベースとなる番号がupstreamの6.6.145より小さくても、Microsoftが必要な修正を取り込んだパッケージとして扱われます。
Azure Linux 3.0では、upstreamの版番号ではなく、MSRCとAzure Linuxのパッケージ情報を基準にしてください。Microsoftの公式パッケージリポジトリには、標準カーネルのkernel-6.6.144.1-1.azl3.x86_64.rpmが掲載されています。(Microsoft Packages)
NVMe-oFターゲットを使用しているか確認する
カーネル版の確認と並行して、対象ホストがNVMe-oFターゲットとして稼働しているかを確認します。
nvmet関連モジュールを確認する
lsmod | grep -E '^nvmet(_|[[:space:]])'nvmet、nvmet_tcp、nvmet_rdmaなどが表示された場合、NVMeターゲット関連モジュールが読み込まれています。
ただし、何も表示されない場合でも、機能がカーネルへ組み込まれている、現在は停止している、設定だけが残っているといった可能性があります。
configfsの設定を確認する
sudo ls -la /sys/kernel/config/nvmet/subsystems 2>/dev/null
sudo ls -la /sys/kernel/config/nvmet/ports 2>/dev/nullサブシステムやポート設定が存在する場合は、次の項目を運用資料や構成管理情報と照合します。
- どのネットワークへ公開しているか
- 接続を許可しているイニシエーター
- DH-HMAC-CHAP認証を使用しているか
- TCP、RDMAなど、利用しているトランスポート
- ファイアウォールやNSGで許可している通信元
- 設定が手動か、構成管理ツールによるものか
nvmetcliを導入している環境では、次の確認も有効です。
sudo nvmetcli lsコマンドやディレクトリが存在しないことだけを根拠に、影響なしと断定しないでください。構成管理リポジトリ、起動スクリプト、systemdユニット、IaCテンプレートも確認する必要があります。
Azure Linux 3.0を修正版へ更新する手順
Azure Linux 3.0では、パッケージ管理にtdnfを使用します。Microsoftの資料でも、一般的なパッケージ更新にはtdnf upgradeが案内されています。(Microsoft Learn)
更新前に確認すること
カーネル更新では再起動が必要になるため、次の準備を行います。
- 現在のカーネル版を記録する
- ストレージターゲットの冗長構成やフェイルオーバーを確認する
/bootを含むディスク空き容量を確認する- 独自ドライバーやカーネルモジュールの互換性を確認する
- NVMe-oFの設定をバックアップする
- 管理コンソールや復旧経路を確保する
- 更新後の接続試験を行えるイニシエーターを準備する
現在の情報を保存する例は次のとおりです。
date
cat /etc/os-release
uname -r
rpm -q kernel
df -h /boot 2>/dev/null || df -h /標準kernelパッケージだけを更新する
変更範囲をカーネルへ限定する場合は、次のコマンドを実行します。
sudo tdnf upgrade kernel実行時には、更新後の版が6.6.144.1-1以上であることを確認してから処理を続行します。
OS全体を更新する
組織の運用方針でOS全体の更新が許可されている場合は、未適用のセキュリティ修正をまとめて反映できます。
sudo tdnf upgrade本番環境では、対象パッケージと依存関係を確認できるよう、最初から-yを付けて自動承認するよりも、トランザクション内容を確認してから実行する方が安全です。
社内ミラーや閉域リポジトリを使用している場合は、修正版パッケージがミラーへ同期済みかも確認してください。公式リポジトリに修正版が存在していても、社内リポジトリの同期が遅れていると更新できません。
インストールされた版を確認する
rpm -q kernel --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n'ここで修正版が表示されても、まだ古いカーネルがメモリ上で動作している可能性があります。
システムを再起動する
sudo rebootストレージターゲットとして運用している場合は、接続中のイニシエーターを切断する、冗長系へ切り替える、アプリケーションのI/Oを停止するといった手順を先に実施してください。
再起動後に稼働カーネルを確認する
uname -r標準kernelパッケージでは、6.6.144.1-1.azl3相当またはそれ以降が表示されることを確認します。
続いて、起動時のエラーを確認します。
systemctl --failed
journalctl -k -b -p warning..alertエラーが出た場合は、カーネル更新そのものだけでなく、ネットワークドライバー、ストレージドライバー、独自モジュール、NVMe-oF設定の読み込み状況も確認します。
更新後に実施すべき動作確認
NVMe-oFターゲットを運用している環境では、uname -rの確認だけで作業を完了させないことが重要です。
| 確認項目 | 確認内容 |
|---|---|
| カーネル | 修正版が実際に稼働している |
| ターゲット設定 | サブシステム、名前空間、ポート設定が復元されている |
| 認証 | 許可されたイニシエーターが正常に認証できる |
| アクセス制御 | 未許可のイニシエーターが拒否される |
| I/O | 読み書き、同期、再接続が正常に行える |
| ログ | カーネルエラー、認証エラー、タイムアウトが発生していない |
| 冗長化 | フェイルオーバーやマルチパスが正常に動作する |
| 監視 | 更新後のホストが監視対象へ戻っている |
イメージからホストを再作成する運用では、稼働中の1台だけを更新しても不十分です。ゴールデンイメージ、VMテンプレート、イメージビルド用Dockerfile、構成管理コードも修正版へ更新してください。そうしなければ、オートスケールや障害復旧時に古いカーネルを持つホストが再作成されます。
すぐに更新できない場合の暫定対策
カーネル更新まで時間が必要な場合は、攻撃者がNVMe-oFターゲットへ到達できる範囲を狭めます。
- NVMe-oF用ネットワークを業務ネットワークや外部ネットワークから分離する
- ファイアウォールやNSGで、許可済みイニシエーターのIPアドレスだけを通す
- 使用していないターゲット、ポート、名前空間を停止する
- 不要な
nvmet関連設定を無効化する - 接続失敗、認証異常、カーネル警告を監視する
- 更新可能になり次第、修正版へ移行する
認証機能を外すことを暫定対策にしてはいけません。 脆弱性が認証処理にあるからといってDH-HMAC-CHAP認証を単純に無効化すると、ストレージが認証なしで接続可能になるなど、別の重大なリスクを生む可能性があります。
使用していないNVMe-oFターゲット機能を停止することと、使用中のターゲットから認証を外すことは別の対応です。
対応時に起きやすい失敗
修正版をインストールしただけで完了にする
カーネルは、インストール後も再起動するまで切り替わりません。
必ず次の2つを分けて確認します。
rpm -q kernel
uname -rrpmはインストール済みパッケージ、uname -rは現在稼働中のカーネルを示します。
upstreamの6.6.145未満だから脆弱と判断する
Azure Linuxでは修正がバックポートされているため、upstreamの数字だけで判定できません。Azure Linux 3.0の標準カーネルでは、MSRCが示す6.6.144.1-1を基準にします。
NVMeディスクがあるだけで攻撃可能と判断する
今回の脆弱性は、単なるNVMeブロックデバイスの読み書きではなく、NVMe-oFターゲットの認証応答処理にあります。
一方で、「現在ターゲットを使っていないから更新しない」という判断も適切ではありません。攻撃経路の有無は対応優先度を決める材料であり、脆弱なパッケージを残す理由にはなりません。
標準kernelと別系列のカーネルを混同する
kernel-hweや独自ビルドを使用している環境では、6.6.144.1-1という標準カーネルの基準をそのまま適用できません。パッケージ名、カーネル系列、ベンダーの修正情報を個別に確認してください。
CWEを推測して公式情報として記録する
境界外読み取りであることから特定のCWEを連想できますが、公開情報ではCWEが掲載されていません。脆弱性管理台帳では「CWE未掲載」と記録し、補助分類を付ける場合は公式情報と区別してください。(NVD)
CVE-2026-64319への対応まとめ
Azure Linux 3.0の標準カーネルを使用している場合、CVE-2026-64319への基本対応は次の流れです。
/etc/os-releaseでAzure Linux 3.0であることを確認するrpm -q kernelでインストール済みカーネルを確認するuname -rで現在稼働しているカーネルを確認する- 標準カーネルが修正版未満なら
tdnfで更新する - システムを再起動する
uname -rで6.6.144.1-1相当以上が稼働していることを確認する- NVMe-oFの認証、接続、I/O、ログを検証する
- ゴールデンイメージや構成管理コードも更新する
CVE-2026-64319は、ネットワーク経由かつ認証前に到達できる可能性があるため、CVSS 9.1と評価されています。ただし、実際の攻撃経路はNVMe-oFターゲットの利用状況やネットワーク公開範囲によって異なります。
まずパッケージの種類と稼働中のカーネルを確認し、標準kernelパッケージを使用している該当ホストは、6.6.144.1-1またはそれ以降のMicrosoft提供版へ更新してください。対応完了の基準は「RPMをインストールしたこと」ではなく、修正版カーネルが実際に起動し、ストレージ機能の動作確認まで完了したことです。
コメント