Azure Linux 3.0でCVE-2026-64320に対応するには、稼働中のカーネルとインストール済みパッケージの両方を確認し、標準のkernelパッケージが6.6.144.1-1未満なら更新したうえで再起動します。MSRCは、Azure Linux 3.0向けの最初の修正版として「azl3 kernel 6.6.144.1-1 on Azure Linux 3.0」を掲載しています。実際のRPMやuname -rでは、6.6.144.1-1.azl3のようにディストリビューション識別子が付く場合があります。(Microsoft Security Response Center)
CVE-2026-64320は、LinuxカーネルのNVMeターゲット機能がDiscoveryログを返す際、要求されたオフセットを十分に検証せず、ヒープ領域の境界外を読み取る可能性がある脆弱性です。NVMeターゲットを外部から到達可能な状態で提供している環境では優先度が高くなります。一方、Azure VMでローカルNVMeディスクを使用しているだけでは、直ちに同じ攻撃経路が公開されているとは限りません。
CVE-2026-64320の概要
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-64320 |
| 対象 | Microsoft Azure Linux 3.0 |
| 対象パッケージ | 標準のkernelパッケージ |
| 脆弱な機能 | LinuxカーネルのNVMeターゲット Discoveryログ処理 |
| 問題の種類 | 境界外ヒープ読み取り |
| 想定される影響 | カーネルメモリ情報の漏えい、カーネルクラッシュ、サービス停止 |
| MSRCのCVSS | 8.4 |
| MSRCのCWE | 掲載なし |
| FirstFixed | kernel 6.6.144.1-1 |
| 必要な対応 | カーネル更新、再起動、稼働バージョン確認 |
MSRCのCWE欄は未掲載です。技術的には境界外読み取りとして説明できますが、資産管理システムや脆弱性台帳に、推測したCWEをベンダー公表値として登録しないよう注意してください。(Microsoft Security Response Center)
NVMe Discoveryログ取得時に何が起きるのか
問題があるのは、NVMe over Fabricsのターゲット側でDiscoveryログを返す処理です。Linuxカーネルのnvmet_execute_disc_get_log_page()は、接続元から受け取ったLog Page Offset、通称lpoについて、DWORD境界にそろっているかは確認していましたが、確保したDiscoveryログ用バッファの範囲内に収まっているかを十分に確認していませんでした。
その結果、攻撃者が指定したオフセットをバッファの先頭アドレスに加え、その位置から要求された長さをコピーする処理で、確保済みヒープ領域を越えてデータが読み取られる可能性があります。脆弱な処理は、Linuxカーネルのdrivers/nvme/target/discovery.cに含まれます。(NVD)
さらに、NVMeのDiscoveryコントローラーは、対象の構成では認証前に到達できる処理です。NVMeターゲットへ接続できるTCP、RDMA、Fibre Channelのピアから、認証前に問題の処理が呼び出される可能性があります。境界外のメモリが読み取られるとカーネル内部の情報が漏えいし、未マップ領域を参照した場合はカーネルのクラッシュやパニックにつながる可能性があります。(NVD)
修正版では、主に次の処理が追加されています。
- 要求されたオフセットがDiscoveryログのサイズ内か検証する
- 実際に存在するデータ量を超えないようコピー長を制限する
- 転送要求に対してデータが不足する部分をゼロで埋める
これにより、Discoveryログ用バッファの後ろにあるカーネルメモリが応答へ混入することを防ぎます。(NVD)
影響を受けるか確認する方法
Azure Linux 3.0であることを確認する
最初に、対象ホストがAzure Linux 3.0であることを確認します。
cat /etc/os-release確認する主な項目はNAMEとVERSION_IDです。VERSION_ID="3.0"など、Azure Linux 3.0であることを確認してください。
コンテナ内でこのコマンドを実行した場合は注意が必要です。コンテナのユーザーランドがAzure Linux 3.0でも、実際に使用されるカーネルはコンテナホストのカーネルです。コンテナイメージ内のOS情報だけでは、CVE-2026-64320への対応状況を判断できません。
現在稼働しているカーネルを確認する
次のコマンドで、今まさに動作しているカーネルを確認します。
uname -r修正版が稼働している場合の表示例は、次のようになります。
6.6.144.1-1.azl36.6.144.1-1.azl3より新しい、Microsoftのサポート対象リポジトリから提供された標準カーネルでも、通常は修正を含みます。FirstFixedは「修正が最初に含まれた版」であり、その版だけを使い続ける必要があるという意味ではありません。
インストール済みのカーネルパッケージを確認する
稼働中のカーネルだけでなく、インストール済みのパッケージも確認します。
rpm -q kernelバージョン、リリース、アーキテクチャを明示したい場合は、次のコマンドが便利です。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel複数世代のカーネルがインストールされている場合、複数行が表示されます。Azure Linux 3.0の公式リポジトリには、標準カーネルのRPMとしてkernel-6.6.144.1-1.azl3.x86_64.rpmが掲載されています。(Microsoft Packages)
結果は次のように判断します。
| 確認結果 | 状態 | 必要な対応 |
|---|---|---|
rpm -q kernelもuname -rも修正版未満 | 未修正 | カーネルを更新して再起動 |
rpm -q kernelには修正版があるが、uname -rは古い | 更新済みだが未反映 | 再起動して新カーネルを読み込む |
uname -rが6.6.144.1-1.azl3 | MSRC掲載の修正版が稼働 | 動作確認を実施 |
uname -rが修正版より新しい | 通常は修正を包含 | パッケージの提供元とサポート状態を確認 |
標準kernelではなく別のカーネル系列 | FirstFixedを単純比較できない | 対象パッケージ系列のMSRC情報を確認 |
バージョンをシェルの文字列比較だけで判定するのは避けてください。たとえば6.6.99と6.6.144を通常の辞書順で比較すると、意図しない判定になることがあります。
標準カーネルか派生カーネルか確認する
システムによっては、標準のkernelではなく、HWE、リアルタイム、64KBページ対応などの別パッケージを使用していることがあります。
rpm -qa 'kernel*' | sort -VMSRCの「azl3 kernel 6.6.144.1-1」というFirstFixedは、標準のkernelパッケージに対する情報です。kernel-hwe、kernel-rt、kernel-64k、独自ビルドカーネルなどを使用している場合は、標準カーネルのバージョン番号だけを根拠に修正済みと判断しないでください。
NVMeターゲット機能が使われているか確認する
CVE-2026-64320はNVMeのターゲット側、つまりストレージを提供する側のnvmetサブシステムに関係します。
ロード済みモジュールは次のように確認できます。
lsmod | grep -E '^(nvmet|nvmet_tcp|nvmet_rdma|nvmet_fc)\b'NVMeターゲットのサブシステム構成は、環境によって次の場所から確認できます。
sudo find /sys/kernel/config/nvmet/subsystems \
-mindepth 1 -maxdepth 1 -type d -print 2>/dev/nullポート設定を確認する例です。
sudo grep -R . \
/sys/kernel/config/nvmet/ports/*/addr_trtype \
/sys/kernel/config/nvmet/ports/*/addr_traddr \
/sys/kernel/config/nvmet/ports/*/addr_trsvcid \
2>/dev/null次の条件に当てはまる場合は、更新の優先度を特に高くする必要があります。
nvmet_tcp、nvmet_rdma、nvmet_fcなどがロードされている- Discovery用サブシステムやポートが構成されている
- NVMeターゲット用ネットワークへ信頼できない端末から到達できる
- ストレージネットワークと一般業務ネットワークが十分に分離されていない
- 外部の接続元にNVMe Discoveryサービスを提供している
一方、Azure VMの一時ディスクやローカルNVMeデバイスを、通常のブロックデバイスとして利用しているだけの場合は、NVMeターゲット機能を提供しているとは限りません。CVEの説明から判断すると、問題となる経路はNVMeのイニシエーター側ではなく、Discoveryログを返すターゲット側です。(NVD)
ただし、lsmodに何も表示されないことだけを理由に、更新不要とは判断しないでください。モジュールが現在ロードされていなくても、将来の構成変更で有効になる可能性があります。パッケージが脆弱な版なら、カーネル更新が基本的な対応です。
Azure Linux 3.0のカーネルを更新する手順
更新前に確認すること
カーネル更新では再起動が必要です。運用環境では、次の点を事前に確認します。
- メンテナンス時間と停止影響
- VMやディスクのバックアップ、復旧手段
- Azure VMのブート診断やシリアルコンソールの利用可否
- GPU、ストレージ、ネットワークなどの追加ドライバーとの互換性
- クラスター構成の場合は、1台ずつ更新できるか
- 再起動後に実施する疎通確認項目
独自カーネルモジュールやベンダー提供ドライバーを使用している場合は、検証環境や少数の先行ホストで更新してから展開するのが安全です。
標準カーネルだけを更新する
変更範囲をカーネル中心に限定する場合は、次のコマンドを実行します。
sudo tdnf update kernel組織の運用方針として、利用可能な更新をまとめて適用する場合は次のコマンドを使用します。
sudo tdnf updateAzure Linux 3.0ではtdnfがパッケージ管理に使用されます。MicrosoftのAzure Linux 3.0向け手順でも、パッケージ更新にtdnf updateが使用されています。(Microsoft Learn)
更新後、修正版がインストールされたことを確認します。
rpm -q kernel再起動して新しいカーネルを有効にする
カーネルパッケージをインストールしただけでは、稼働中のカーネルは切り替わりません。
sudo systemctl reboot再起動後に、次のコマンドを実行します。
uname -r期待する結果は、次のいずれかです。
6.6.144.1-1.azl3または、Microsoftのサポート対象リポジトリから提供された、これより新しい標準カーネルです。
再起動後の動作を確認する
カーネル版だけでなく、サービスの状態も確認します。
systemctl --failed --no-pager今回の起動で発生した重大なログを確認します。
journalctl -b -p err..alert --no-pagerNVMeターゲットを運用している場合は、次の項目も確認してください。
- Discovery処理が正常に応答する
- 既存のNVMeイニシエーターから再接続できる
- 名前空間とサブシステムの構成が維持されている
- TCP、RDMA、FCのうち利用中のトランスポートが正常に動作する
- ストレージ監視で新たなエラーや遅延が発生していない
更新しても古いカーネルが表示される場合
rpm -q kernelには6.6.144.1-1.azl3が表示されるのに、uname -rが古い場合、修正版はインストールされていますが、まだ起動されていません。
まず再起動を実施します。それでも古い版が起動する場合は、次の点を確認してください。
| 確認点 | よくある原因 |
|---|---|
| 再起動が実際に行われたか | サービス再起動だけで済ませている |
| ブートエントリー | 古いカーネルが既定になっている |
| 更新したホスト | 別のVMや別ノードを確認している |
| パッケージ名 | 標準kernelとは別系列を使用している |
| 自動化処理 | 更新後の再起動工程が実行されていない |
| 脆弱性スキャナー | 再スキャン前の古いインベントリが残っている |
「パッケージ更新完了」を対応完了の条件にせず、再起動後のuname -r確認までを完了条件にすることが重要です。
リポジトリに修正版が見つからない場合
tdnf update kernelを実行しても修正版が提示されない場合は、リポジトリ設定を確認します。
tdnf repolist続いて、インストール中のカーネルとアーキテクチャを確認します。
rpm -q kernel
uname -m確認すべき項目は次のとおりです。
- Azure Linux 3.0用の本番リポジトリが有効か
- 古いスナップショットリポジトリへ固定されていないか
- プロキシやDNSの問題でメタデータ更新に失敗していないか
- カーネルパッケージが更新除外対象になっていないか
- 使用しているイメージやリポジトリミラーの同期が遅れていないか
Microsoftの公式Azure Linux 3.0本番リポジトリには、標準カーネル6.6.144.1-1.azl3のRPMが掲載されています。(Microsoft Packages)
本番リポジトリで更新が見つからないという理由だけで、プレビューリポジトリからRPMを直接取得して強制インストールするのは避けてください。リポジトリ設定やミラーの同期状況を確認し、組織がサポート対象としている配布経路から更新します。
AKSのAzure Linux 3.0ノードで対応する場合
Azure Kubernetes Serviceのノードでは、各ノードへSSH接続してtdnf update kernelを繰り返す方法より、AKSのノードイメージ更新機能を使用する方法が基本です。
現在のノードイメージと利用可能な更新を確認します。
az aks nodepool get-upgrades \
--resource-group <リソースグループ> \
--cluster-name <クラスター名> \
--nodepool-name <ノードプール名>現在のノードイメージを確認します。
az aks nodepool show \
--resource-group <リソースグループ> \
--cluster-name <クラスター名> \
--name <ノードプール名> \
--query nodeImageVersion \
-o tsv特定のノードプールだけを更新する場合は、次のコマンドを使用します。
az aks nodepool upgrade \
--resource-group <リソースグループ> \
--cluster-name <クラスター名> \
--name <ノードプール名> \
--node-image-onlyすべてのノードプールのイメージを更新する場合は、次のコマンドを使用できます。
az aks upgrade \
--resource-group <リソースグループ> \
--name <クラスター名> \
--node-image-only \
--yesMicrosoftはAKSのノードイメージを定期的に更新しており、手動更新のほか、ノードOS自動アップグレードチャネルの利用を推奨しています。ノードイメージ更新では、Kubernetesのバージョンを変更せずにOSカーネルやセキュリティ修正を反映できます。(Microsoft Learn)
現在のノードOSアップグレードチャネルは、次のコマンドで確認できます。
az aks show \
--resource-group <リソースグループ> \
--name <クラスター名> \
--query autoUpgradeProfileNodeImageチャネルでは、セキュリティ修正とバグ修正を含む新しいノードイメージが、設定したメンテナンス期間に従って適用されます。更新時はノードのcordonとdrainが発生するため、PodDisruptionBudget、レプリカ数、最大サージ値も確認してください。(Microsoft Learn)
すぐに更新できない場合の一時的な対策
カーネル更新と再起動をすぐに実施できない場合は、NVMeターゲットへの到達経路を制限します。
- NVMe-oF用ネットワークを一般業務ネットワークから分離する
- NSG、ファイアウォール、ACLで接続元を必要なイニシエーターに限定する
- インターネットや信頼できないネットワークからの到達を遮断する
- 不要なNVMeターゲット構成やDiscovery用ポートを停止する
- 監視ログで不審なDiscovery要求やカーネルエラーを確認する
NVMeターゲット機能の停止やモジュールの解除は、稼働中のストレージ接続を切断する可能性があります。影響を確認せずに実施しないでください。
これらは攻撃経路を狭めるための一時対策です。境界外読み取りそのものを修正するものではないため、最終的には修正版カーネルの導入と再起動が必要です。
CVSSが情報源によって異なる理由に注意する
MSRCのAzure Linux 3.0向け情報では、CVE-2026-64320のCVSSは8.4とされています。一方、Linux CNA由来のNVD情報では、CVSS 3.1の基本値として9.1が掲載されており、ネットワーク経由、低い攻撃条件、権限不要、ユーザー操作不要、機密性と可用性への高い影響というベクターが示されています。(Microsoft Security Response Center)
脆弱性台帳では、次のように情報源を分けて記録すると混乱を防げます。
| 記録項目 | 推奨する記載 |
|---|---|
| ベンダー評価 | MSRC CVSS 8.4 |
| 汎用CVE評価 | Linux CNA／NVD CVSS 9.1 |
| 修正版の判断根拠 | MSRCのAzure Linux 3.0向けFirstFixed |
| 技術的な攻撃経路 | Linux CNA／NVDの脆弱性説明 |
スコアが異なるからといって、どちらかが必ず誤りというわけではありません。製品別の修正版判断ではMSRCを優先し、横断的なリスク比較では使用しているスコアの提供元を明記することが重要です。
対応時に起きやすい失敗
| 失敗例 | 問題点 | 正しい対応 |
|---|---|---|
tdnf updateだけで完了とする | 古いカーネルが動き続ける | 再起動後にuname -rを確認 |
rpm -q kernelだけを見る | インストール済み版と稼働版を混同する | rpm -q kernelとuname -rを両方確認 |
| FirstFixedと完全一致しないと未修正と判断する | より新しい修正版まで誤検知する | 同じサポート系列の後続版を許容 |
| 標準カーネルとHWEなどを同じ基準で比較する | 異なるパッケージ系列を誤判定する | 実際のパッケージ名を確認 |
| NVMeディスクを使っているだけで外部攻撃可能と判断する | イニシエーター側とターゲット側を混同する | nvmet構成と到達経路を確認 |
| コンテナ内だけを調査する | ホストカーネルの状態を見落とす | コンテナホストやAKSノードを確認 |
| CWEを推測して確定値として登録する | MSRC公表情報と台帳が不一致になる | 「MSRCでは未掲載」と記録 |
| プレビューRPMを直接導入する | サポート外構成や依存関係問題を招く | 本番のサポート対象リポジトリを使用 |
CVE-2026-64320対応の最終確認
Azure Linux 3.0で標準のkernelパッケージを使用している場合は、まず次の2つを実行します。
uname -r
rpm -q kernel修正版未満なら、サポート対象リポジトリからカーネルを更新します。
sudo tdnf update kernel
sudo systemctl reboot再起動後に、修正版が実際に稼働していることを確認します。
uname -r6.6.144.1-1.azl3または同じサポート系列の後続版が稼働していることを確認し、NVMeターゲットを提供している環境では接続試験まで実施してください。AKSの場合は、ノードへ個別に変更を加えるのではなく、ノードイメージ更新またはノードOS自動アップグレードチャネルで対応します。
コメント