CVE-2026-64508とは？Azure Linux 3.0のBPF JIT脆弱性と修正版6.6.144.1-1

Microsoft Azure Linux 3.0でCVE-2026-64508に対応するには、標準カーネルを「6.6.144.1-1」以上の修正版へ更新し、再起動後に新しいカーネルが実際に動作していることを確認する必要があります。MSRCは、最初に修正された版として「azl3 kernel 6.6.144.1-1 on Azure Linux 3.0」を掲載しています。CVSSスコアは7.8で、CWEは掲載されていません。(Microsoft Security Response Center)

重要なのは、更新パッケージをインストールするだけでは対応が完了しない点です。Linuxカーネルは再起動するまで切り替わらないため、rpmでインストール済みパッケージを確認すると同時に、uname -rで現在実行中のカーネルを確認してください。

CVE-2026-64508の要点

項目	内容
CVE番号	`CVE-2026-64508`
対象	Microsoft Azure Linux 3.0
対象コンポーネント	LinuxカーネルのBPF JIT
問題	BPF JITメモリ再利用時の分岐予測状態に対する防御不足
想定される攻撃	BPF JITスプレーを利用した攻撃チェーンの成立を助ける可能性
CVSS	7.8
CWE	MSRCには掲載なし
FirstFixed	`azl3 kernel 6.6.144.1-1 on Azure Linux 3.0`
必要な対応	カーネル更新、再起動、稼働中カーネルの再確認

Microsoftの公式パッケージリポジトリには、x86_64向けのkernel-6.6.144.1-1.azl3.x86_64.rpmと、Arm64向けの同バージョンのパッケージが掲載されています。(Microsoft Packages)

BPF JITスプレー攻撃への耐性不足とは

BPF JITが行っていること

BPFは、Linuxカーネル内で小さなプログラムを実行する仕組みです。ネットワーク制御、パケットフィルタリング、監視、セキュリティ製品、コンテナネットワークなどで広く利用されています。

BPFプログラムは、そのまま逐次解釈するだけでなく、BPF JITによってCPUが直接実行できるネイティブ命令へ変換されることがあります。JITは「Just-In-Time」の略で、実行速度を高められる一方、生成されたコードを配置する実行可能メモリの管理がセキュリティ上の重要なポイントになります。

CVE-2026-64508で問題になった処理

LinuxカーネルのBPF JITアロケーターは、複数の小さなBPFプログラムを大きな実行可能メモリ領域へまとめて配置します。プログラムが削除されると、その空き領域は後から読み込まれた別のプログラムに再利用されます。

問題は、以前のプログラムが存在していた場所へ新しいコードを書き込んだ際に、CPUの間接分岐予測に古いプログラムの状態が残る可能性があったことです。その結果、新しいプログラムへの間接ジャンプが、以前のコードによって作られた予測状態を再利用するおそれがありました。

修正では、BPF JITメモリを再利用する前に、必要なアーキテクチャで間接分岐予測の状態をフラッシュできる仕組みが追加されています。これにより、古いコードの分岐予測状態が新しいコードへ引き継がれることを防ぎます。(CVE)

単独でリモート侵入を成立させる脆弱性とは限らない

CVE-2026-64508は、BPF JITスプレーに対する防御を強化する修正です。「Azure Linuxをインターネットへ公開しているだけで、ただちに外部から侵入される」という種類の問題として捉えるのは適切ではありません。

一方で、攻撃者が低い権限でコードを実行できる環境や、不特定のコードを頻繁に実行する環境では、別の脆弱性と組み合わせた攻撃チェーンの信頼性を高める可能性があります。CVSSが7.8であることからも、単なる軽微な不具合として放置すべきではありません。

対応を優先したい環境

実際の更新優先度は、CVSSだけでなく、サーバー上で誰がどのようなコードを実行できるかによって判断します。

環境	推奨優先度	判断理由
複数部署や複数顧客が利用する共有ホスト	最優先	信頼度の異なるコードが同じカーネルを共有する
共有CI/CDランナー	最優先	外部ライブラリやビルドスクリプトを継続的に実行する
特権コンテナを使用するホスト	最優先	ホストカーネルへ影響できる権限が大きい
マルチユーザーの開発サーバー	高	ローカルコードを実行できる利用者が複数存在する
eBPFベースのネットワーク・監視・セキュリティ製品を使うホスト	高	更新後の動作確認を含めて早めに対応したい
管理者だけが利用する単一用途の専用サーバー	通常の緊急保守枠	攻撃面は比較的小さいが、未修正カーネルの放置は避ける
Azure Linuxのコンテナイメージ	ホスト側を確認	コンテナは原則としてホストのカーネルを使用する

コンテナ内の/etc/os-releaseがAzure Linux 3.0を示していても、実際に使われているカーネルはコンテナホスト側のものです。コンテナイメージだけを更新しても、ホストのカーネルが古ければCVE-2026-64508の対応にはなりません。

修正版6.6.144.1-1を正しく理解する

Azure LinuxではMSRCのFirstFixedを基準にする

MSRCが示す修正版は、Azure Linux 3.0の標準kernelパッケージである6.6.144.1-1です。

RPMファイル名では、次のような表記になります。

kernel-6.6.144.1-1.azl3.x86_64

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

kernel-6.6.144.1-1.azl3.aarch64

同じ標準kernelパッケージ系列で、これより新しいMicrosoft提供版を利用している場合は、通常は過去の修正も含まれます。ただし、独自ビルドや異なるカーネル系列を単純にバージョン番号だけで比較してはいけません。

Linux上流の6.6.145と食い違って見える理由

LinuxカーネルのCVE情報では、上流の6.6系について6.6.145が修正版として示されています。一方、Azure Linux 3.0ではMSRCが6.6.144.1-1をFirstFixedとしています。(NVD)

これは矛盾ではありません。Linuxディストリビューションでは、上流の修正コミットを既存バージョンへバックポートすることがあります。そのため、Azure Linuxの6.6.144.1-1には、上流のバージョン番号を6.6.145へ上げずに必要な修正が取り込まれている場合があります。

Azure Linux 3.0の判定では、次の順番で情報を優先してください。

MSRCが示すAzure Linux向けFirstFixed
Microsoft公式リポジトリのパッケージ
実際にインストールされているRPMのバージョン
再起動後に動作しているカーネル

上流カーネルの数字だけを見て「6.6.145未満だから未修正」と判断すると、バックポート済みのAzure Linuxパッケージを誤判定する可能性があります。

カーネルの種類が異なる場合は別途確認する

MSRCのFirstFixedは、製品名にazl3 kernelと記載された標準カーネル向けです。

次のような別系列を使用している場合、kernel 6.6.144.1-1をそのまま修正基準として適用しないでください。

kernel-hwe
kernel-64k
kernel-rt
kernel-ipe
kernel-mshv
ベンダーや組織が独自にビルドしたカーネル

別系列では、バージョン、バックポート状況、公開タイミングが異なる可能性があります。現在使っているパッケージ名を確認したうえで、該当するMicrosoftの更新情報を確認します。

Azure Linux 3.0が該当するか確認する手順

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

最初に、対象マシンがAzure Linux 3.0であることを確認します。

grep -E '^(NAME|ID|VERSION_ID|PRETTY_NAME)=' /etc/os-release

VERSION_IDが3.0になっていることを確認してください。

Azureポータル上のVM名や社内の資産管理台帳だけで判断するのは避けます。イメージの再作成や移行後に、台帳と実際のOSが一致していない可能性があるためです。

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

uname -r

この結果は、現在メモリ上で稼働しているカーネルです。

修正版へ更新済みであれば、環境によって次のような形式で表示されます。

6.6.144.1-1.azl3.x86_64

アーキテクチャやビルド形式によって末尾は異なるため、完全一致する文字列としてではなく、使用中のパッケージ系列と合わせて判断します。

インストールされている標準カーネルを確認する

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

Linuxでは、ロールバック用として複数のカーネルがインストールされている場合があります。すべてのカーネル関連パッケージを確認するには、次のコマンドを使います。

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  | grep '^kernel' \
  | sort

結果にkernel-6.6.144.1-1.azl3以上の標準カーネルが含まれているかを確認します。

確認結果の判断方法

インストール状況	`uname -r`	判定
修正版が未インストール	古いカーネル	未修正。更新と再起動が必要
修正版がインストール済み	古いカーネル	再起動待ち、または起動カーネルの選択に問題がある
修正版がインストール済み	修正版が稼働中	カーネル更新は完了
標準`kernel`が見つからない	別系列またはホスト側カーネル	カーネル種別や実行環境を再確認
コンテナ内で確認している	ホストのカーネルが表示される	コンテナホスト側を調査

パッケージがインストール済みでも、uname -rが古いままであれば修正は有効になっていません。

CVE-2026-64508を修正する更新手順

更新前に確認すること

本番環境のカーネルを更新する前に、最低限次の項目を確認します。

バックアップ、スナップショット、再構築手段があるか
SSHで接続できなくなった場合に、シリアルコンソールなどを利用できるか
/bootに十分な空き容量があるか
GPUドライバーやDKMSなどの外部カーネルモジュールを利用していないか
クラスターの場合は、対象ノードをドレインできるか
ロードバランサーから安全に切り離せるか
再起動によるサービス停止時間を確保できるか

特にGPUドライバー、ストレージドライバー、監視エージェント、eBPFベースのセキュリティ製品を利用している場合は、検証環境で先に起動確認を行うと安全です。

利用可能なカーネルを確認する

sudo tdnf clean all
sudo tdnf info kernel

表示された利用可能バージョンが、少なくとも6.6.144.1-1.azl3以上であることを確認します。

標準カーネルを更新する

sudo tdnf upgrade kernel -y

MicrosoftのAzure Linux 3向け手順でも、カーネル更新にはtdnf upgrade kernelを実行し、その後に再起動する方法が案内されています。(Microsoft Learn)

組織の更新方針として、検証済みの全パッケージをまとめて更新する場合は、次の方法もあります。

sudo tdnf upgrade -y

ただし、全体更新ではカーネル以外のライブラリやサービスも変更されます。影響範囲を限定したい緊急対応では、まずkernelパッケージだけを更新する方法が判断しやすいでしょう。

再起動する

sudo reboot

新しいカーネルは、パッケージをインストールした時点ではまだ動作していません。再起動して新しいカーネルを読み込む必要があります。

再起動後に修正版が動作しているか確認する

uname -r

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

標準カーネルを利用している場合は、uname -rに6.6.144.1-1.azl3以上が表示されていることを確認します。

続いて、起動時の問題を確認します。

systemctl --failed

journalctl -k -b -p warning..alert --no-pager

エラーがない場合でも、次の項目は実際に動作確認してください。

ネットワーク接続
DNS名前解決
ストレージやファイルシステムのマウント
コンテナランタイム
Azureエージェント
GPUやアクセラレーター
監視・ログ収集エージェント
eBPFを使うネットワーク機能
ファイアウォールやセキュリティポリシー
業務アプリケーションのヘルスチェック

新しいカーネルで正常に起動したことを確認するまでは、旧カーネルを削除しない方が安全です。

修正版が表示されない場合の確認項目

tdnf info kernelやtdnf upgrade kernelで6.6.144.1-1以上が表示されない場合、非公式サイトからRPMを直接ダウンロードするのではなく、次の項目を確認します。

リポジトリ設定

ls -l /etc/yum.repos.d/
grep -R '^\(baseurl\|enabled\|name\)=' /etc/yum.repos.d/

無効化されたリポジトリや、古い社内ミラーだけを参照していないか確認します。

社内ミラーの同期待ち

インターネット上のMicrosoft公式リポジトリにパッケージが存在していても、社内ミラーへまだ同期されていない場合があります。

この場合は、クライアント側で何度更新を実行しても修正版は表示されません。ミラー管理者へ次のパッケージが同期済みか確認します。

kernel-6.6.144.1-1.azl3

バージョン固定

パッケージのバージョンロックや、構成管理ツールによる固定が設定されていると、修正版が候補から除外される場合があります。

grep -R 'kernel' /etc/tdnf /etc/yum.repos.d/ 2>/dev/null

Ansible、Packer、イメージビルドパイプラインなどでバージョンを固定している場合も確認してください。

カーネル系列の違い

rpm -qa | grep '^kernel'

kernel-hweやkernel-rtなどを使っている場合、標準kernelのFirstFixedは直接適用できません。標準カーネルを無理に追加すると、起動対象や外部モジュールの依存関係が変わる可能性があります。

AKSのAzure Linux 3.0ノードで対応する場合

Azure Kubernetes Serviceのノードでは、ノードへSSH接続してtdnfを手動実行するより、修正済みのノードイメージへ更新する方法が基本です。

手動で変更したノードは、スケール、修復、再イメージ化によって置き換えられる可能性があります。イメージ側が古いままだと、新しく作られたノードで未修正カーネルが再び使われます。

現在のノードイメージを確認する

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

特定のノードプールのイメージだけを更新する

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

Kubernetesのバージョンを変更せず、ノードプールのOSイメージだけを更新できます。Microsoftは、手動更新のほか、ノードOSイメージの自動アップグレードチャネルの利用も案内しています。(Microsoft Learn)

更新後に各ノードのカーネルを確認する

kubectl get nodes \
  -o custom-columns='NAME:.metadata.name,KERNEL:.status.nodeInfo.kernelVersion,OS:.status.nodeInfo.osImage'

ノードプールの一部だけが古い状態で残ることがあるため、クラスター全体ではなく各ノード単位で確認します。

更新前にはPodDisruptionBudget、ノードサージ、DaemonSet、空き容量、ステートフルワークロードの配置を確認してください。

すぐに更新できない場合の一時的な対策

保守枠をすぐに確保できない場合は、更新までの短期間に限り、攻撃面を縮小します。

不要なローカルアカウントやSSHアクセスを停止する
信頼できないコードを対象ホストで実行しない
共有CI/CDランナーを別の更新済みホストへ移す
特権コンテナの実行を一時的に制限する
CAP_BPFやCAP_SYS_ADMINを付与したコンテナを確認する
マルチテナント環境では、信頼度の低いワークロードを隔離する
更新済みノードへワークロードを移動する

現在のBPF設定は、次のコマンドで確認できます。

sysctl kernel.unprivileged_bpf_disabled 2>/dev/null
sysctl net.core.bpf_jit_enable 2>/dev/null
sysctl net.core.bpf_jit_harden 2>/dev/null

非特権BPFやBPF JITが無効であれば、一部の攻撃経路が制限されている可能性はあります。ただし、これらの設定だけで「修正済み」と判断することはできません。

また、BPF JITを検証なしで無効化すると、ネットワーク性能、監視、セキュリティエージェント、コンテナネットワークへ影響する可能性があります。一時対策を恒久対応の代わりにせず、最終的にはMicrosoft提供カーネルへ更新してください。

対応時によくある失敗

失敗例	問題点
`tdnf upgrade kernel`だけ実行して終了する	再起動するまで古いカーネルが動作し続ける
`rpm -q kernel`だけ確認する	修正版がインストール済みでも、実行中とは限らない
`uname -r`だけ確認する	インストール済みの別カーネルや更新候補を把握できない
上流の`6.6.145`だけを基準にする	Azure Linuxのバックポート済みパッケージを誤判定する
標準カーネルのFirstFixedをHWEやRTへ適用する	パッケージ系列ごとに修正状況が異なる可能性がある
コンテナイメージだけを更新する	ホストカーネルは更新されない
既存VMだけ更新する	古いゴールデンイメージから未修正VMが再作成される
1台だけ確認して全台対応済みとする	ノードプールや更新ウェーブごとに版が異なることがある
非公式サイトからRPMを取得する	署名、依存関係、供給元の信頼性を保証できない
旧カーネルをすぐ削除する	新カーネルで起動できない場合の復旧手段を失う

更新後はイメージと自動化設定も修正する

稼働中のVMを更新しても、元となるイメージや構築スクリプトが古いままでは、次回のスケールアウトや障害復旧で未修正環境が再作成されます。

カーネル更新後は、次の対象も見直してください。

Azure Compute Galleryのイメージ
VM Scale Setsの参照イメージ
Packerのビルド定義
TerraformやBicepのデプロイ設定
AKSノードイメージと自動アップグレードチャネル
CI/CDランナーのベースイメージ
社内リポジトリやパッケージミラー
脆弱性スキャナーの例外設定
資産管理台帳のカーネル情報

CVE-2026-64508への対応は、RPMを一度インストールするだけでは完了しません。Azure Linux 3.0の標準カーネルを6.6.144.1-1以上へ更新し、再起動後にuname -rで修正版が稼働していることを確認し、さらに将来作成されるVMやノードのイメージも更新するところまで実施してください。

この記事を書いた人

佐藤健司

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

CVE-2026-64508とは？Azure Linux 3.0のBPF JIT脆弱性と修正版6.6.144.1-1

CVE-2026-64508の要点

BPF JITスプレー攻撃への耐性不足とは

BPF JITが行っていること

CVE-2026-64508で問題になった処理

単独でリモート侵入を成立させる脆弱性とは限らない

対応を優先したい環境

修正版6.6.144.1-1を正しく理解する

Azure LinuxではMSRCのFirstFixedを基準にする

Linux上流の6.6.145と食い違って見える理由

カーネルの種類が異なる場合は別途確認する

Azure Linux 3.0が該当するか確認する手順

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

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

インストールされている標準カーネルを確認する

確認結果の判断方法

CVE-2026-64508を修正する更新手順

更新前に確認すること

利用可能なカーネルを確認する

標準カーネルを更新する

再起動する

再起動後に修正版が動作しているか確認する

修正版が表示されない場合の確認項目

リポジトリ設定

社内ミラーの同期待ち

バージョン固定

カーネル系列の違い

AKSのAzure Linux 3.0ノードで対応する場合

現在のノードイメージを確認する

特定のノードプールのイメージだけを更新する

更新後に各ノードのカーネルを確認する

すぐに更新できない場合の一時的な対策

対応時によくある失敗

更新後はイメージと自動化設定も修正する

この記事を書いた人

コメント

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

CVE-2026-64508とは？Azure Linux 3.0のBPF JIT脆弱性と修正版6.6.144.1-1

CVE-2026-64508の要点

BPF JITスプレー攻撃への耐性不足とは

BPF JITが行っていること

CVE-2026-64508で問題になった処理

単独でリモート侵入を成立させる脆弱性とは限らない

対応を優先したい環境

修正版6.6.144.1-1を正しく理解する

Azure LinuxではMSRCのFirstFixedを基準にする

Linux上流の6.6.145と食い違って見える理由

カーネルの種類が異なる場合は別途確認する

Azure Linux 3.0が該当するか確認する手順

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

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

インストールされている標準カーネルを確認する

確認結果の判断方法

CVE-2026-64508を修正する更新手順

更新前に確認すること

利用可能なカーネルを確認する

標準カーネルを更新する

再起動する

再起動後に修正版が動作しているか確認する

修正版が表示されない場合の確認項目

リポジトリ設定

社内ミラーの同期待ち

バージョン固定

カーネル系列の違い

AKSのAzure Linux 3.0ノードで対応する場合

現在のノードイメージを確認する

特定のノードプールのイメージだけを更新する

更新後に各ノードのカーネルを確認する

すぐに更新できない場合の一時的な対策

対応時によくある失敗

更新後はイメージと自動化設定も修正する

この記事を書いた人

関連記事

コメント

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

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