CVE-2026-64475：Azure Linux 3.0のVFIO PCI解放不備と修正版への更新手順

CVE-2026-64475への対処では、Azure Linux 3.0のカーネルを確認し、標準のkernelパッケージを利用している場合は、6.6.144.1-1.azl3以上へ更新して再起動することが重要です。MSRCは、Azure Linux 3.0向けの最初の修正版としてazl3 kernel 6.6.144.1-1 on Azure Linux 3.0を掲載しています。

この脆弱性は、VFIO PCIデバイスの登録に失敗した際、VGAアービターへの登録を正しく解除できない問題です。CVSS基本値は8.8と高い一方、攻撃元区分はローカルです。すべてのAzure Linux 3.0環境が同じ危険度になるわけではありませんが、PCIパススルーやGPU割り当てにVFIOを使用するホストは優先的に確認する必要があります。(Microsoft Security Response Center)

CVE-2026-64475の概要

項目	内容
CVE番号	`CVE-2026-64475`
対象	Microsoft Azure Linux 3.0
コンポーネント	Linuxカーネルの`vfio/pci`
問題	デバイス登録失敗時にVGAアービターのクライアント登録が残る
想定される影響	解放済みのVFIOデバイス情報をコールバックが参照する可能性
CVSS	8.8、重要度High
攻撃元区分	ローカル
CWE	MSRCおよびNVDでは未掲載
Azure Linux 3.0のFirstFixed	`kernel 6.6.144.1-1`
必要な対応	カーネル更新、再起動、稼働中バージョンの確認

NVDに掲載されたCVSSベクトルは、CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hです。攻撃にはローカルでの低い権限が必要ですが、成功した場合は機密性・完全性・可用性に大きな影響が及ぶ評価になっています。(NVD)

VFIO PCI登録失敗時に何が起きるのか

VFIOは、PCIデバイスをユーザー空間のアプリケーションや仮想マシンから利用するためのLinuxカーネル機構です。代表的な用途には、次のようなものがあります。

GPUを仮想マシンへ直接割り当てる
ネットワークカードやストレージコントローラーをPCIパススルーする
QEMUやKVMから物理デバイスを直接操作する
特定のアクセラレーターをユーザー空間ドライバーから利用する

一方、VGAアービターは、複数のVGA互換デバイスが存在する環境で、従来のVGAリソースをどのデバイスが使用するか調整する仕組みです。

CVE-2026-64475では、vfio_pci_core_register_device()がデバイスを登録する途中で問題が発生した場合の後片付けに不備がありました。

処理の流れを簡略化すると、次のようになります。

段階	正常な動作	問題がある動作
VFIOデバイスの初期化	デバイス情報を作成する	同じ
VGAアービターへの登録	コールバックとデバイス情報を登録する	同じ
後続処理	登録に成功する	途中で失敗する
エラー処理	登録済みリソースを逆順に解除する	VGAアービターの解除が抜ける
その後	不要な参照は残らない	解放済みの`vdev`を指す登録が残り得る

Linuxカーネル側の説明では、処理順序の変更によりvfio_pci_vga_init()が最後の失敗地点ではなくなったにもかかわらず、新しい失敗経路にVGA登録の解除処理が追加されていなかったとされています。

現在のコードでは直ちに問題化しにくい経路もあるものの、登録されたコールバックに解放済みのvdev情報が残る可能性があります。コールバックが後からVFIOデバイスをたどる実装では、安全でない参照につながります。修正では、登録失敗時に必要なVGA側の後片付けが実行されるようになりました。(NVD)

CVSS 8.8でも「インターネットから直接攻撃される」とは限らない

CVSS 8.8という数値だけを見ると、外部から直ちに攻撃される重大な脆弱性に見えるかもしれません。しかし、今回のベクトルでは攻撃元区分がAV:Lです。

これは、一般的な評価上、攻撃者が対象システム上で何らかのコードを実行できることを前提にしています。認証なしでネットワーク越しに直接到達できる脆弱性とは性質が異なります。

ただし、ローカル攻撃だから後回しにしてよいとは限りません。次の環境では優先度を上げるべきです。

優先度	環境の例	判断理由
高	VFIOによるGPU・PCIパススルーを利用している	問題のあるコード経路を利用する可能性が高い
高	複数利用者がログインする仮想化ホスト	低権限ユーザーからの攻撃可能性を考慮する必要がある
高	信頼できない処理に`/dev/vfio/*`を公開している	VFIOデバイスへアクセスできる主体が増える
高	デバイスのバインド・解除を頻繁に行う	登録失敗やエラー処理の発生機会が増える
中	VFIOモジュールはあるが現在使用していない	現在の露出は低くても将来有効化される可能性がある
通常	VFIOを使用せず、管理者だけが利用する単一用途サーバー	緊急度は相対的に低いが、カーネル更新は必要

CVSSは環境固有の危険度ではなく、脆弱性そのものの基本評価です。実際の対応順は、VFIOの利用状況、ローカル利用者の範囲、仮想化構成、サービス停止の影響を合わせて決めます。

Azure Linux 3.0が該当するか確認する方法

OSの種類とバージョンを確認する

まず、対象システムがAzure Linux 3.0であることを確認します。

cat /etc/os-release

VERSION_IDなどの項目を確認し、Azure Linux 3.0であることを判断します。他のディストリビューションやAzure Linuxの別バージョンに、今回のFirstFixedをそのまま適用してはいけません。

現在動作しているカーネルを確認する

次に、メモリ上で実際に動作しているカーネルを確認します。

uname -r

修正版を使用している場合の出力例は、次のようになります。

6.6.144.1-1.azl3.x86_64

ARM64環境では、末尾のアーキテクチャ表記が異なります。

MicrosoftのAzure Linux 3.0本番用リポジトリには、kernel-6.6.144.1-1.azl3.x86_64.rpmとkernel-6.6.144.1-1.azl3.aarch64.rpmが掲載されています。(Microsoft Packages)

インストール済みカーネルを確認する

現在動作しているカーネルとは別に、ディスク上にインストールされているパッケージも確認します。

rpm -q kernel

パッケージ名、バージョン、リリース番号、アーキテクチャを分けて表示する場合は、次のコマンドが便利です。

rpm -q kernel \
  --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n'

カーネル関連パッケージ全体を確認する場合は、次のように実行します。

rpm -qa | grep -E '^kernel(-|$)' | sort

結果の判断では、次の違いが重要です。

確認結果	状態	対応
修正版カーネルがインストールされていない	未修正	パッケージを更新する
`rpm -q kernel`には修正版があるが、`uname -r`は旧版	更新後に未再起動	再起動する
`uname -r`が`6.6.144.1-1.azl3`以上	FirstFixed以上が稼働	動作確認とログ確認を行う
標準の`kernel`ではなく別フレーバーを利用	単純比較できない	対応するパッケージ行をMSRCで確認する

修正版パッケージをインストールしただけでは対応完了になりません。 カーネルは再起動するまで置き換わらないため、最終判定にはuname -rを使用します。

VFIOを使用しているか調べる方法

VFIOの利用状況は、対応の優先順位を決める材料になります。

VFIOモジュールの読み込み状態を確認する

lsmod | grep -E '^vfio'

次のようなモジュールが表示される場合、VFIO関連機能が読み込まれています。

vfio_pci
vfio_pci_core
vfio_iommu_type1
vfio

ただし、何も表示されないから安全とは限りません。モジュールが現在読み込まれていないだけで、設定やワークロードの起動によって後から利用される可能性があります。

PCIデバイスのドライバーを確認する

lspciが利用できる場合は、GPUなどがvfio-pciへ割り当てられていないか確認します。

lspci -nnk | grep -A3 -E \
  'VGA compatible controller|3D controller|Display controller'

出力に次の表示がある場合、そのデバイスはVFIO PCIドライバーを使用しています。

Kernel driver in use: vfio-pci

設定ファイルも検索しておくと、起動時に自動バインドされる構成を把握できます。

grep -R --line-number -E 'vfio-pci|vfio_pci' \
  /etc/modprobe.d /etc/default/grub 2>/dev/null

VFIOを使用していないことは、カーネル更新を省略する理由にはなりません。これはあくまで、検証順序やメンテナンスの優先順位を決めるための確認です。

Azure Linux 3.0で修正版カーネルへ更新する手順

更新前に確認すること

カーネル更新には再起動が必要です。実行前に、少なくとも次の項目を確認します。

VMやディスクのバックアップ、または復旧手段がある
シリアルコンソールなど、起動失敗時の接続手段がある
再起動可能なメンテナンス時間を確保している
外部カーネルモジュールや独自ドライバーの互換性を確認している
クラスター構成では対象ノードからワークロードを退避している
PCIパススルー先の仮想マシンを安全に停止できる

特にGPUドライバーやDKMSで構築されたモジュールを使用している環境では、更新後のカーネル向けモジュールが用意されるか確認してください。

システムを再起動する

sudo reboot

再起動せずにrpm -q kernelだけを確認して作業を終了すると、旧カーネルが引き続き動作します。

更新後に修正を確認する

稼働中のカーネルを再確認する

再接続後、最初に次のコマンドを実行します。

uname -r

標準のkernelパッケージでは、次のいずれかであることを確認します。

6.6.144.1-1.azl3を含む
それより新しいAzure Linux 3.0公式カーネルである

次に、インストール済みパッケージと稼働中カーネルをまとめて記録します。

printf 'Running kernel: '
uname -r

printf '\nInstalled kernel packages:\n'
rpm -q kernel \
  --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n'

カーネルログを確認する

起動後に重大な警告が出ていないか確認します。

sudo journalctl -k -b -p warning..alert

VFIO、IOMMU、VGA、PCIに関連するメッセージを絞り込む場合は、次のように実行します。

sudo journalctl -k -b | \
  grep -iE 'vfio|iommu|vga|pci'

すべての警告が脆弱性や更新失敗を意味するわけではありません。更新前のログと比較し、以前になかったエラーが増えていないかを確認します。

PCIパススルーを動作確認する

VFIOを実際に利用している環境では、次の項目も確認します。

vfio-pciへ割り当てたデバイスが正しく認識される
対象仮想マシンが起動する
GPUやNICなどのデバイスがゲストOSから利用できる
仮想マシンの停止と再起動が正常に行える
デバイスのリセットや再割り当てでエラーが出ない
ホスト側のjournalctlに新しいVFIOエラーが記録されない

旧カーネルは、更新後の動作確認が終わるまで削除しない方が安全です。

AKSのAzure Linuxノードではノードイメージを更新する

Azure Kubernetes ServiceでAzure Linux 3.0を使用している場合、個々のノードへSSH接続してtdnfを実行する方法を恒久的な対応にするのは適切ではありません。

AKSでは、ノードイメージのアップグレードを使用して、修正済みカーネルを含むイメージへノードを更新します。

利用可能な更新を確認します。

az aks nodepool get-upgrades \
  --nodepool-name "$AKS_NODEPOOL" \
  --cluster-name "$AKS_CLUSTER" \
  --resource-group "$AKS_RESOURCE_GROUP"

現在のノードイメージを確認します。

az aks nodepool show \
  --resource-group "$AKS_RESOURCE_GROUP" \
  --cluster-name "$AKS_CLUSTER" \
  --name "$AKS_NODEPOOL" \
  --query nodeImageVersion

特定のノードプールだけを更新する場合は、次のように実行します。

az aks nodepool upgrade \
  --resource-group "$AKS_RESOURCE_GROUP" \
  --cluster-name "$AKS_CLUSTER" \
  --name "$AKS_NODEPOOL" \
  --node-image-only

クラスター内の全ノードプールを更新する場合は、次のコマンドを利用できます。

az aks upgrade \
  --resource-group "$AKS_RESOURCE_GROUP" \
  --name "$AKS_CLUSTER" \
  --node-image-only \
  --yes

更新後は、各ノードのイメージバージョンを確認します。

kubectl get nodes \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.kubernetes\.azure\.com\/node-image-version}{"\n"}{end}'

AKSではノードイメージの自動アップグレードや、SecurityPatch、NodeImageなどのノードOSアップグレードチャネルも利用できます。単発の修正だけでなく、今後のカーネル脆弱性に継続して対応できる運用へ切り替えることが重要です。(Microsoft Learn)

`6.6.144.1-1`の読み方で注意すること

6.6.144.1-1は、CVE-2026-64475の影響を受けるバージョンではなく、MSRCがAzure Linux 3.0向けに示した最初の修正版です。

次のような判断は避けてください。

Linux本家のカーネル番号だけで修正済みか判断する
6.6.144の部分だけを比較する
RPMのリリース番号-1やazl3を無視する
他のLinuxディストリビューションの修正バージョンを流用する
kernel-hweやkernel-64kへ標準kernelの判定を無条件に適用する

Linuxディストリビューションでは、上流の修正を既存バージョンへバックポートすることがあります。そのため、Azure LinuxではMSRCが示す製品行と、RPMのVERSION-RELEASEを基準に判断します。

すぐに再起動できない場合の暫定対応

修正版の適用と再起動が最優先です。業務上の理由ですぐに再起動できない場合は、恒久対策までの間、次のリスク低減策を検討します。

新しいPCIパススルー設定を追加しない
不要なVFIOデバイス割り当てを停止する
/dev/vfio/*へアクセスできるユーザーやコンテナを制限する
信頼できないローカルユーザーのログインを制限する
特権コンテナやホストデバイス公開の設定を見直す
VFIOデバイスのバインド・解除操作を必要最小限にする
再起動可能な最短のメンテナンス時間を確保する

これらは脆弱性を修正するものではありません。古いカーネルが動作している限り、対応済みとして扱わないでください。

対応完了の判断基準

CVE-2026-64475への対応は、パッケージをダウンロードした時点では完了しません。次の条件をすべて満たしたことを確認します。

対象がAzure Linux 3.0であることを確認した
使用中のカーネルフレーバーを確認した
標準kernelでは6.6.144.1-1以上をインストールした
システムまたはノードを再起動した
uname -rで修正版カーネルの稼働を確認した
VFIOやPCIパススルーの動作確認を実施した
カーネルログに新たな重大エラーがないことを確認した
VMイメージ、VMSS、AKSノードイメージなどの生成元も更新した
資産管理や脆弱性管理システムへ証跡を記録した

まずは各ホストで、次の3つを実行してください。

cat /etc/os-release
uname -r
rpm -q kernel

Azure Linux 3.0の標準カーネルが6.6.144.1-1.azl3未満であれば、最新のkernelパッケージへ更新し、再起動後にuname -rを再確認します。AKSでは個別更新ではなくノードイメージを更新し、すべてのノードプールが修正版へ切り替わったことを確認しましょう。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

CVE-2026-64475：Azure Linux 3.0のVFIO PCI解放不備と修正版への更新手順

CVE-2026-64475の概要

VFIO PCI登録失敗時に何が起きるのか

CVSS 8.8でも「インターネットから直接攻撃される」とは限らない

Azure Linux 3.0が該当するか確認する方法

OSの種類とバージョンを確認する

現在動作しているカーネルを確認する

インストール済みカーネルを確認する

VFIOを使用しているか調べる方法

VFIOモジュールの読み込み状態を確認する

PCIデバイスのドライバーを確認する

Azure Linux 3.0で修正版カーネルへ更新する手順

更新前に確認すること

最新の標準カーネルをインストールする

システムを再起動する

更新後に修正を確認する

稼働中のカーネルを再確認する

カーネルログを確認する

PCIパススルーを動作確認する

AKSのAzure Linuxノードではノードイメージを更新する

`6.6.144.1-1`の読み方で注意すること

すぐに再起動できない場合の暫定対応

対応完了の判断基準

この記事を書いた人

コメント

コメントするコメントをキャンセル

CVE-2026-64475：Azure Linux 3.0のVFIO PCI解放不備と修正版への更新手順

CVE-2026-64475の概要

VFIO PCI登録失敗時に何が起きるのか

CVSS 8.8でも「インターネットから直接攻撃される」とは限らない

Azure Linux 3.0が該当するか確認する方法

OSの種類とバージョンを確認する

現在動作しているカーネルを確認する

インストール済みカーネルを確認する

VFIOを使用しているか調べる方法

VFIOモジュールの読み込み状態を確認する

PCIデバイスのドライバーを確認する

Azure Linux 3.0で修正版カーネルへ更新する手順

更新前に確認すること

最新の標準カーネルをインストールする

システムを再起動する

更新後に修正を確認する

稼働中のカーネルを再確認する

カーネルログを確認する

PCIパススルーを動作確認する

AKSのAzure Linuxノードではノードイメージを更新する

6.6.144.1-1の読み方で注意すること

すぐに再起動できない場合の暫定対応

対応完了の判断基準

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

`6.6.144.1-1`の読み方で注意すること

コメントするコメントをキャンセル