CVE-2026-64389対策：Azure Linux 3.0のksmbdを修正版カーネルへ更新

Azure Linux 3.0でCVE-2026-64389に対応するには、標準のkernelパッケージを6.6.144.1-1以上へ更新し、再起動後に新しいカーネルが実際に稼働していることを確認します。RPMやuname -rでは、通常6.6.144.1-1.azl3のようにAzure Linux固有のリリース文字列が付きます。

MSRCは、Azure Linux 3.0向けの最初の修正版であるFirstFixedとして「azl3 kernel 6.6.144.1-1 on Azure Linux 3.0」を掲載しています。MSRC上のCVSS基本値は7.8で、CWEは掲載されていません。更新パッケージをインストールしただけでは不十分で、再起動前の旧カーネルが動いている間は修正が有効にならない点に注意が必要です。(Microsoft Security Response Center)

CVE-2026-64389の概要

CVE-2026-64389は、Linuxカーネルに含まれるSMBサーバー実装ksmbdにおいて、NTLMv2応答を検証する順序が不適切だった問題です。

項目	内容
CVE番号	CVE-2026-64389
対象	Microsoft Azure Linux 3.0
関連コンポーネント	Linuxカーネルの`ksmbd`
関連処理	NTLMv2認証、SMB3マルチチャネルのセッションバインディング
問題の内容	NTLMv2応答の検証が完了する前にセッションキーが更新される
想定される影響	既存SMBセッションの整合性や可用性への影響
MSRCのCVSS	7.8
MSRCのCWE	掲載なし
FirstFixed	`azl3 kernel 6.6.144.1-1 on Azure Linux 3.0`
管理者が行うこと	カーネル更新、再起動、稼働版の再確認

ksmbdは、SMB3によるネットワークファイル共有をカーネル空間で処理するLinuxのSMBサーバーです。NTLM／NTLMv2認証やSMB3暗号化、SMB3マルチチャネルなどをサポートし、通常はTCPポート445でSMB要求を待ち受けます。(Linuxカーネルドキュメント)

NTLMv2応答の検証不備で何が起きるのか

NTLMv2認証では、クライアントから送信された応答が正しいことを検証してから、その認証結果に基づくセッションキーを使用する必要があります。

しかし、脆弱なksmbdでは、おおむね次の順序で処理が進んでいました。

ksmbd_auth_ntlmv2()がNTLMv2セッションキーを算出する
検証が完了する前に、算出結果を既存セッションのsess->sess_keyへ書き込む
NT proofの不一致によって認証が失敗する
それにもかかわらず、後続のKEY_XCH処理が継続する
最終的にはSTATUS_LOGON_FAILUREが返るが、既存セッションキーは変更されている可能性がある

特に問題になるのが、SMB3マルチチャネルのセッションバインディングです。この処理では、新規セッションではなく既存セッションに対して認証処理が行われます。そのため、不正なNT proofを含む要求でも、認証失敗が返される前に既存セッションのキーが変更される可能性があります。

修正版では、セッションキーを一度ローカルバッファーへ生成し、NTLMv2応答が正しいと確認できた場合だけsess->sess_keyへコピーするよう変更されています。また、認証失敗時には直ちに処理を終了し、KEY_XCHへ進まないよう修正されています。(NVD)

単純なログイン突破とは異なる

公開されている技術説明では、不正な資格情報でSMB共有へのログインに成功するとはされていません。最終的な応答はSTATUS_LOGON_FAILUREです。

一方で、認証失敗前に既存セッションキーへ影響を与えられるため、正規ユーザーのSMB接続を不安定にしたり、既存セッションの整合性を損なったりする可能性があります。したがって、「認証には失敗するから問題ない」と判断するのは適切ではありません。

NVDに表示されているkernel.orgのCNA評価では、機密性への影響なし、完全性への限定的な影響、可用性への大きな影響を示すCVSSベクトルが掲載されています。(NVD)

Azure Linux 3.0が対象か確認する方法

まず、OS、稼働中のカーネル、インストール済みのカーネルを分けて確認します。

cat /etc/os-release

printf 'Running kernel: '
uname -r

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

各コマンドの役割は次のとおりです。

コマンド	確認できること
`cat /etc/os-release`	Azure Linux 3.0であるか
`uname -r`	現在実際に動いているカーネル
`rpm -q kernel`	インストール済みの標準カーネル
`rpm -qa \| grep '^kernel'`	標準以外も含むカーネル関連パッケージ

バージョンの判断基準

標準のkernelパッケージを使用している場合は、次のように判断します。

確認結果	判断と対応
稼働中のカーネルが`6.6.144.1-1.azl3`より前	更新と再起動が必要
修正版がインストール済みだが、`uname -r`は旧版	再起動が必要
`uname -r`が`6.6.144.1-1.azl3`またはそれ以降	標準カーネルでは修正済み
`kernel`パッケージが見つからない	コンテナ、派生カーネル、独自カーネルの可能性を確認
`kernel-hwe`や`kernel-64k`を使用	標準`kernel`の基準をそのまま適用せず、使用中のパッケージ系列を確認

MSRCの6.6.144.1-1は「その版だけを使う」という意味ではなく、最初に修正が含まれた版を示しています。Microsoftの公式リポジトリから提供される、それより新しい標準カーネルも修正済みとして扱えます。

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

上流Linuxの修正版と番号が違う理由

NVDでは、上流Linuxカーネルについて6.18系や7.1系の修正版情報も掲載されています。一方、Azure Linux 3.0の標準カーネルは6.6系です。

これは、Microsoftが必要な修正をAzure Linuxの6.6系カーネルへバックポートしているためです。Azure Linux 3.0では、上流Linuxのバージョン番号ではなく、MSRCが示すAzure Linux向けFirstFixedを基準にしてください。(NVD)

ksmbdが実際に使用されているか確認する

古いカーネルが入っていることと、外部から直ちに攻撃可能であることは同じではありません。優先順位を決めるため、ksmbdの稼働状況とTCPポート445の公開範囲を確認します。

if [ -d /sys/module/ksmbd ]; then
  echo "ksmbd is loaded or built into the running kernel"
else
  echo "ksmbd is not currently active"
fi

sudo ss -lntp | grep -E '(:|\])445[[:space:]]'

pgrep -af 'ksmbd.mountd'

lsmod | grep ksmbdでもロード済みモジュールを確認できますが、カーネルへ組み込まれている場合はlsmodだけでは判断できません。そのため、/sys/module/ksmbdやポート445の待ち受けも併せて確認します。

対応の優先度は、次のように考えられます。

状況	優先度
`ksmbd`が稼働し、TCP 445がインターネットや広いネットワークへ公開されている	最優先
`ksmbd`を社内ネットワークで使用している	高
SMB3マルチチャネルを有効化している	高
`ksmbd`は停止中だが、古いカーネルが稼働している	更新対象
モジュール未使用でポート445も閉じている	即時の露出は低いが、計画的な更新が必要

現在使っていなくても、運用変更や自動起動によって将来ロードされる可能性があります。ksmbdが停止中という理由だけでカーネル更新を省略するのは避けてください。

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

更新前に確認すること

本番環境では、更新前に次の点を確認します。

VMのバックアップまたは復旧可能なスナップショット
再起動できるメンテナンス時間
/bootとルートファイルシステムの空き容量
GPUドライバーや独自カーネルモジュールの互換性
SMB共有を利用しているクライアントへの影響
冗長構成の場合は一台ずつ更新できること

空き容量は次のコマンドで確認できます。

df -h / /boot 2>/dev/null

標準カーネルだけを更新する

CVE-2026-64389への対応を優先し、変更範囲をカーネルに限定する場合は、次のコマンドを実行します。

sudo tdnf upgrade kernel -y

Azure Linux 3では、カーネル更新にtdnf upgrade kernelを使用できます。(Microsoft Learn)

更新後、インストールされたパッケージを確認します。

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

出力例は次のようになります。

kernel-6.6.144.1-1.azl3.x86_64

aarch64環境では、末尾が.aarch64になります。

OS全体を更新する場合

通常の定期メンテナンスとして、他のセキュリティ更新もまとめて適用する場合は、次のコマンドを使用します。

sudo tdnf upgrade -y

カーネルだけを更新する方法は変更範囲を抑えやすい一方、ほかの未適用脆弱性は残ります。緊急対応ではカーネルのみ、定期メンテナンスではOS全体というように、テスト範囲と運用方針に応じて選択してください。

再起動する

新しいカーネルは、インストールしただけでは稼働しません。

sudo reboot

再接続後、必ず次のコマンドを実行します。

uname -r

標準カーネルでは、少なくとも次の文字列を含む版が稼働していることを確認します。

6.6.144.1-1.azl3

それより新しいMicrosoft公式の標準カーネルが表示される場合も問題ありません。

更新後に確認する項目

カーネル版だけでなく、サービスへの影響も確認します。

uname -r

sudo ss -lntp | grep -E '(:|\])445[[:space:]]'

journalctl -k -b -p warning

実務では、次の確認まで行うと安全です。

SMBクライアントから再接続できる
NTLMv2認証が正常に完了する
ファイルの読み書き、名前変更、削除ができる
マルチチャネルを使用している場合は複数経路で接続できる
GPUやストレージなどの追加カーネルモジュールが正常にロードされる
起動時にカーネルパニックやモジュール読み込みエラーが発生していない

更新できない場合に確認するポイント

tdnfで修正版が表示されない

tdnf upgrade kernelを実行しても更新候補がない場合は、次の点を確認します。

Azure Linux 3.0の本番リポジトリが有効になっているか
社内ミラーへ最新パッケージが同期されているか
プロキシ、DNS、ファイアウォールでMicrosoftのリポジトリが遮断されていないか
使用しているCPUアーキテクチャがx86_64かaarch64か
標準kernelではなく、別のカーネル系列を使用していないか
パッケージのバージョン固定や除外設定が入っていないか

キャッシュの問題が疑われる場合は、リポジトリ設定を確認したうえでメタデータを再取得します。

sudo tdnf clean all
sudo tdnf upgrade kernel -y

インターネット上のRPMを直接ダウンロードして強制的にインストールするより、構成済みの公式リポジトリまたは管理された社内ミラーを使用する方が、署名検証や依存関係の管理を行いやすくなります。

再起動しても古いカーネルが動く

修正版がインストール済みなのにuname -rが変わらない場合は、ブートローダーが旧カーネルを選択している可能性があります。

この場合は、次の点を確認します。

GRUBのデフォルト起動エントリー
新しいカーネル用のinitramfsが作成されているか
/boot内のカーネルと設定ファイル
Secure Bootや独自署名の要件
起動失敗後に旧カーネルへ自動的に戻っていないか

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

派生カーネルを使用している

kernel-hwe、kernel-64kなどを使用している環境では、標準kernel向けの6.6.144.1-1をそのまま比較基準にしないでください。

次のコマンドで、実際にインストールされている系列を確認します。

rpm -qa | grep '^kernel' | sort

派生カーネルでは、使用中のパッケージ系列に対してMicrosoftが提供する最新版へ更新し、該当CVEの修正を含むかをMSRCやパッケージ情報で確認します。

AKSのAzure Linux 3.0ノードでの対応

Azure Kubernetes ServiceでAzure Linux 3.0ノードを使用している場合は、各ノードへSSH接続して個別にtdnfを実行するのではなく、基本的にAKSのノードイメージ更新で統一します。

利用可能なノードイメージを確認します。

az aks nodepool get-upgrades \
  --nodepool-name <NODEPOOL> \
  --cluster-name <CLUSTER> \
  --resource-group <RESOURCE_GROUP>

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

az aks nodepool show \
  --resource-group <RESOURCE_GROUP> \
  --cluster-name <CLUSTER> \
  --name <NODEPOOL> \
  --query nodeImageVersion

修正版を含む新しいノードイメージが利用可能になったら、対象ノードプールを更新します。

az aks nodepool upgrade \
  --resource-group <RESOURCE_GROUP> \
  --cluster-name <CLUSTER> \
  --name <NODEPOOL> \
  --node-image-only

AKSのLinuxノードイメージは定期的に更新されますが、リージョン全体への展開に時間差が生じることがあります。最新イメージがまだ表示されない場合は、AKSのリリース状況を確認しつつ、TCP 445の公開制限などの暫定対策を行います。(Microsoft Learn)

複数ノードプールがある場合は、一つのノードプールだけを更新して完了としないよう注意してください。

Azure Linuxコンテナで検出された場合の考え方

コンテナは、原則としてホストOSのLinuxカーネルを共有します。そのため、Azure Linux 3.0のコンテナイメージに対してスキャナーがCVE-2026-64389を報告した場合でも、実際の対応対象がコンテナ内ではなく、AKSノードやコンテナホストのカーネルである可能性があります。

次のように整理します。

実行環境	主な更新対象
Azure Linux 3.0 VM	VMの`kernel`パッケージ
AKSのAzure Linux 3.0ノード	AKSノードイメージ
通常のアプリケーションコンテナ	コンテナホストのカーネル
カーネルを含む仮想アプライアンス	アプライアンス内のカーネル

コンテナイメージを再ビルドしただけで、ホストの旧カーネルが更新されるわけではありません。スキャン結果では、脆弱なパッケージが「どこに存在するか」だけでなく、「どのカーネルが実際に実行されているか」を確認することが重要です。

すぐに更新できない場合の暫定対策

修正版への更新と再起動が最終的な対応です。メンテナンス時間を直ちに確保できない場合は、攻撃経路を減らすために次の対策を検討します。

Azure NSGやホストファイアウォールでTCP 445の公開範囲を必要最小限にする
インターネットからTCP 445へ直接接続できる構成を解消する
ksmbdを使用していない場合は、運用手順に従って停止する
SMB接続元を管理用サブネットや必要なクライアントに限定する
SMB3マルチチャネルが不要なら、影響を検証したうえで一時的に無効化する
不審な認証失敗やSMBセッション切断の増加を監視する

今回の公開説明で問題となっているのはSMB3マルチチャネルのバインディング処理ですが、マルチチャネルの無効化やポート制限は修正版の適用を置き換えるものではありません。

CVSSが7.8と8.2のどちらで表示される理由

MSRCではCVE-2026-64389のCVSSが7.8とされています。一方、NVDでは確認時点でNVD自身の評価は未掲載ですが、kernel.orgのCNA評価として8.2が表示されています。(Microsoft Security Response Center)

評価主体や使用するベクトルが異なると、同じCVEでもスコアが一致しない場合があります。

情報源	表示される評価
MSRC	CVSS 7.8
NVD上のkernel.org CNA評価	CVSS 8.2
NVD自身の評価	確認時点では未掲載
CWE	MSRCでは掲載なし

Azure Linux 3.0への適用判断では、スコアを平均したり、高い方だけを採用したりするのではなく、Microsoftが示す対象製品とFirstFixedを基準にします。いずれのスコアでも対応を後回しにできる軽微な問題ではありません。

対応時に起こりやすい失敗

インストール済みパッケージだけを見て完了にする

rpm -q kernelに修正版が表示されても、uname -rが旧版なら修正は有効になっていません。最後の判定には必ずuname -rを使用します。

6.6.144.1だけを比較する

RPMの版は、バージョン、リリース、Azure Linux固有文字列、アーキテクチャを含みます。6.6.144.1だけでなく、少なくとも6.6.144.1-1.azl3まで確認してください。

FirstFixedを脆弱な版だと誤解する

FirstFixedは、最初に修正された版です。6.6.144.1-1は避けるべき版ではなく、標準カーネルにおける修正済みの基準です。

ksmbdを使っていないため更新しない

現在ロードされていなくても、古いカーネルには脆弱なコードが残っています。将来の設定変更やサービス起動も考慮し、通常のセキュリティ更新として適用します。

AKSの一部ノードだけを更新する

一台だけ修正版でも、旧ノードが残っていればクラスタ全体として対応済みとはいえません。全ノードプールと全ノードの更新状況を確認します。

コンテナ内だけを更新する

コンテナが使用するカーネルはホスト側です。コンテナイメージの更新とホストカーネルの更新を混同しないようにします。

CVE-2026-64389への対応を完了するチェックリスト

まず、Azure Linux 3.0の各ホストで次のコマンドを実行します。

uname -r

標準カーネルが6.6.144.1-1.azl3より前なら、修正版へ更新します。

sudo tdnf upgrade kernel -y
sudo reboot

再起動後、もう一度確認します。

uname -r

最後に、次の状態になっていることを確認してください。

稼働中の標準カーネルが6.6.144.1-1.azl3またはそれ以降
SMB共有へ正常に再接続できる
TCP 445が必要なネットワークだけに制限されている
AKSではすべての対象ノードプールが更新されている
派生カーネルでは、そのパッケージ系列の修正版を確認している
資産管理台帳や脆弱性管理ツールへ更新結果を記録している

CVE-2026-64389では、修正版を「インストールしたか」ではなく、修正版カーネルで現在起動しているかが最終的な判定基準です。

この記事を書いた人

佐藤健司

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

CVE-2026-64389対策：Azure Linux 3.0のksmbdを修正版カーネルへ更新

CVE-2026-64389の概要

NTLMv2応答の検証不備で何が起きるのか

単純なログイン突破とは異なる

Azure Linux 3.0が対象か確認する方法

バージョンの判断基準

上流Linuxの修正版と番号が違う理由

ksmbdが実際に使用されているか確認する

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

更新前に確認すること

標準カーネルだけを更新する

OS全体を更新する場合

再起動する

更新後に確認する項目

更新できない場合に確認するポイント

tdnfで修正版が表示されない

再起動しても古いカーネルが動く

派生カーネルを使用している

AKSのAzure Linux 3.0ノードでの対応

Azure Linuxコンテナで検出された場合の考え方

すぐに更新できない場合の暫定対策

CVSSが7.8と8.2のどちらで表示される理由

対応時に起こりやすい失敗

インストール済みパッケージだけを見て完了にする

6.6.144.1だけを比較する

FirstFixedを脆弱な版だと誤解する

ksmbdを使っていないため更新しない

AKSの一部ノードだけを更新する

コンテナ内だけを更新する

CVE-2026-64389への対応を完了するチェックリスト

この記事を書いた人

コメント

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

CVE-2026-64389対策：Azure Linux 3.0のksmbdを修正版カーネルへ更新

CVE-2026-64389の概要

NTLMv2応答の検証不備で何が起きるのか

単純なログイン突破とは異なる

Azure Linux 3.0が対象か確認する方法

バージョンの判断基準

上流Linuxの修正版と番号が違う理由

ksmbdが実際に使用されているか確認する

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

更新前に確認すること

標準カーネルだけを更新する

OS全体を更新する場合

再起動する

更新後に確認する項目

更新できない場合に確認するポイント

tdnfで修正版が表示されない

再起動しても古いカーネルが動く

派生カーネルを使用している

AKSのAzure Linux 3.0ノードでの対応

Azure Linuxコンテナで検出された場合の考え方

すぐに更新できない場合の暫定対策

CVSSが7.8と8.2のどちらで表示される理由

対応時に起こりやすい失敗

インストール済みパッケージだけを見て完了にする

6.6.144.1だけを比較する

FirstFixedを脆弱な版だと誤解する

ksmbdを使っていないため更新しない

AKSの一部ノードだけを更新する

コンテナ内だけを更新する

CVE-2026-64389への対応を完了するチェックリスト

この記事を書いた人

関連記事

コメント

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

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