MENU

CVE-2026-64437とは？Azure Linux 3.0のksmbd脆弱性と修正版・更新手順

Linux

Azure Linux 3.0でCVE-2026-64437に対応するには、稼働中のカーネルとインストール済みのカーネルパッケージを確認し、標準のkernelパッケージが修正版未満なら更新後に再起動します。MSRCがFirstFixedとして示しているのは、azl3 kernel 6.6.144.1-1 on Azure Linux 3.0です。RPMの表示では、通常kernel-6.6.144.1-1.azl3の形式になります。Microsoftの公式リポジトリでも、x86_64版とAArch64版の該当パッケージを確認できます。(Microsoft Security Response Center)

この脆弱性は、LinuxカーネルのSMBサーバー実装であるksmbdにおいて、SMB2_CLOSEに続いてSMB2_CANCELが処理された際、解放済みのメモリを再び参照する問題です。MSRCでのCVSSスコアは7.8で、CWEは掲載されていません。更新をインストールしただけでは不十分であり、新しいカーネルで起動したことまで確認する必要があります。

目次

CVE-2026-64437の概要

項目内容
CVE番号CVE-2026-64437
対象Microsoft Azure Linux 3.0
影響するコンポーネントLinuxカーネルのksmbd
脆弱性の内容解放済みメモリ使用、Use-After-Free
発生する処理SMB2_CLOSEの後に同じ非同期処理へSMB2_CANCELが送信される
MSRCのCVSS7.8
CWEMSRCには掲載なし
FirstFixedazl3 kernel 6.6.144.1-1 on Azure Linux 3.0
RPMでの主な表示例kernel-6.6.144.1-1.azl3.x86_64

CWEが掲載されていないからといって、脆弱性の内容が不明という意味ではありません。技術的にはUse-After-Freeですが、脆弱性管理台帳へ登録する際は、MSRCの項目にCWEがないことと、一般的な脆弱性の種類を分けて記録すると誤解を防げます。(Microsoft Security Response Center)

SMB2_CLOSE後に解放済みメモリ使用が発生する仕組み

ksmbdは、Linuxカーネル内でSMBサーバー機能を提供するコンポーネントです。今回の問題は、ファイルロックに関する非同期処理の終了状態とキャンセル処理の管理が適切に連動していなかったことに起因します。

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

  1. SMBクライアントからのロック要求が待機状態となり、非同期処理として管理されます。
  2. 対象ハンドルにSMB2_CLOSEが送られると、処理状態がKSMBD_WORK_CLOSEDへ変更されます。
  3. 待機していたワーカーが終了処理を行い、ロック情報であるfile_lockを解放します。
  4. しかし、非同期要求の一覧にはキャンセル関数への参照が残ります。
  5. 同じAsyncIdに対してSMB2_CANCELが送られると、解放済みのfile_lockを使ってキャンセル処理が実行されます。

つまり、すでに不要になって解放されたメモリへの参照が残り、その参照が後から再利用される状態です。Linuxの公式CVEレコードでは、認証済みSMBクライアントから操作し、KASANを有効にした環境でUse-After-Freeが再現されています。

解放済みメモリ使用は、カーネルのクラッシュやシステムの不安定化、メモリ破損などにつながる可能性があります。ただし、実際に生じる影響はカーネル構成や攻撃方法によって異なるため、根拠なく任意コード実行まで断定すべきではありません。

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

確認では、次の3点を分けて調べます。

  • OSがAzure Linux 3.0か
  • どのカーネルパッケージがインストールされているか
  • 現在どのカーネルで稼働しているか

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

cat /etc/os-release
uname -r

/etc/os-releaseでAzure Linux 3.0であることを確認します。

uname -rは、現在メモリへ読み込まれて稼働しているカーネルを表示します。修正版をインストール済みでも再起動していない場合、ここには古いバージョンが表示されます。

想定される修正版の表示例は次のとおりです。

6.6.144.1-1.azl3.x86_64

AArch64環境では、末尾がaarch64になる場合があります。

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

標準のkernelパッケージは、次のコマンドで確認できます。

rpm -q kernel

カーネル関連パッケージをまとめて確認する場合は、次のコマンドを使います。

rpm -qa | grep -E '^kernel' | sort -V

判断方法は次のとおりです。

確認結果判断と対応
rpm -q kernelにもuname -rにも修正版がないカーネル更新と再起動が必要
RPMには修正版があるがuname -rは古い更新は導入済みだが再起動が必要
uname -rが6.6.144.1-1.azl3以降標準kernel系列では修正反映済みと判断できる
kernel-hweやkernel-mshvなどを使用標準kernelのFirstFixedをそのまま適用せず、該当パッケージ系列を個別確認
Azure Linux 3.0ではないこのMSRCのFirstFixedだけで判定しない

特に見落としやすいのが、インストール済みカーネルと稼働中カーネルの違いです。脆弱性スキャナーでは修正版がインストール済みと判定されても、再起動前で古いカーネルが動いていれば、実際の修正は有効になっていません。

ksmbdの利用状況を確認する

現在ksmbdモジュールが読み込まれているかは、次のコマンドで確認できます。

lsmod | grep '^ksmbd'

カーネルのビルド設定を参照できる環境では、次の確認も有効です。

grep '^CONFIG_SMB_SERVER=' /boot/config-$(uname -r) 2>/dev/null

SMBで利用されるTCP 445番ポートの待ち受け状況は、次のように確認できます。

sudo ss -lntp | grep ':445'

ksmbdが読み込まれ、TCP 445番ポートが信頼できないネットワークから到達可能な環境は、優先して対応すべきです。

一方、コマンドの結果が空でも、直ちに「影響なし」とは判断できません。現在は無効でも、設定変更や将来の運用で有効化される可能性があります。パッチ適用の要否は、現在の公開状態だけではなく、MSRCが示す製品とパッケージの該当性を基準に判断します。

修正版はkernel 6.6.144.1-1.azl3

Azure Linux 3.0の標準kernelパッケージについて、MSRCが示す最初の修正版は次の版です。

azl3 kernel 6.6.144.1-1 on Azure Linux 3.0

実際のRPMパッケージ名は、アーキテクチャに応じて次のようになります。

kernel-6.6.144.1-1.azl3.x86_64
kernel-6.6.144.1-1.azl3.aarch64

Microsoftの公式パッケージリポジトリには、両アーキテクチャ向けの6.6.144.1-1.azl3が公開されています。(Microsoft Packages)

FirstFixedは更新先の固定指定ではなく最低ライン

FirstFixedは、脆弱性が初めて修正されたバージョンです。そのため、必ず6.6.144.1-1へ固定してインストールするという意味ではありません。

適用時に、同じ標準kernel系列の新しい修正版がリポジトリで提供されている場合は、通常はその時点で提供されている最新のサポート版へ更新します。古い修正版へ意図的に固定すると、後から修正された別の脆弱性を取り込めない可能性があります。

上流Linuxカーネルの番号だけで判定しない

Linuxの公式CVEレコードでは、上流の6.6系列について6.6.145が修正版として扱われています。一方、Azure Linux 3.0では6.6.144.1-1.azl3がFirstFixedです。

これは必ずしも矛盾ではありません。Azure Linuxは安定性を維持するため、カーネルなどの中核コンポーネントに修正をバックポートし、大きなバージョン変更を抑える方針を採っています。したがって、上流カーネルの番号だけを見て「6.6.145未満だから未修正」と判定するのではなく、Azure Linux向けパッケージのリリース番号とMSRCのFirstFixedを基準にすることが重要です。(Microsoft Learn)

Azure Linux 3.0のカーネルを更新する手順

更新前に準備すること

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

  • メンテナンス時間と再起動時間を確保する
  • Azure Serial Consoleなど、起動障害時の接続手段を確認する
  • 必要に応じてディスクのスナップショットやバックアップを取得する
  • 独自カーネルモジュールやGPUドライバーとの互換性をテストする
  • 複数台構成では一斉更新を避け、先行検証用の1台から更新する

カーネル更新では再起動が必要です。ロードバランサー配下のサーバーでは、対象ノードを切り離してから更新するとサービス停止を抑えられます。

利用可能なパッケージを確認する

sudo tdnf list kernel

表示される候補に、6.6.144.1-1.azl3または同じ標準kernel系列の新しい版が含まれていることを確認します。

パッケージを更新する

Azure Linuxでは、RPMとtdnfを使ってパッケージを管理します。一般的な更新コマンドは次のとおりです。(Microsoft Learn)

sudo tdnf upgrade

このコマンドはカーネル以外の更新も対象にする可能性があります。実行前にトランザクションの内容を確認し、本番環境では事前検証と変更管理を行ってください。

更新後、インストールされたカーネルを確認します。

rpm -q kernel

出力例は次のとおりです。

kernel-6.6.144.1-1.azl3.x86_64

システムを再起動する

sudo systemctl reboot

SSH接続が切断されるため、再接続できる状態になるまで監視します。

再起動後に修正反映を確認する

uname -r
rpm -q kernel

uname -rが次の版、または同じ標準kernel系列の新しい修正版になっていることを確認します。

6.6.144.1-1.azl3.x86_64

最後に、アプリケーション、SMB共有、監視エージェント、ネットワーク接続などの正常性も確認します。バージョン確認だけで作業を終了すると、カーネル更新に伴うドライバーやサービスの問題を見逃すことがあります。

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

Azure Kubernetes ServiceでAzure Linux 3.0を使用している場合、各ノードへSSH接続してtdnfを実行する方法を恒久的な更新手段にしないことが重要です。ノードの再作成時に手動変更が失われるため、AKSのノードイメージ更新を利用します。

利用可能なノードイメージを確認する例は次のとおりです。

az aks nodepool get-upgrades \
  --resource-group <リソースグループ名> \
  --cluster-name <クラスター名> \
  --nodepool-name <ノードプール名>

現在のノードイメージは次のコマンドで確認できます。

az aks nodepool show \
  --resource-group <リソースグループ名> \
  --cluster-name <クラスター名> \
  --name <ノードプール名> \
  --query nodeImageVersion \
  --output tsv

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

az aks nodepool upgrade \
  --resource-group <リソースグループ名> \
  --cluster-name <クラスター名> \
  --name <ノードプール名> \
  --node-image-only

AKSではLinuxノードイメージが定期的に更新され、Microsoftは自動更新チャネルや計画メンテナンスの利用も案内しています。Pod Disruption Budget、ノードサージ、メンテナンス時間を確認してから更新してください。(Microsoft Learn)

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

カーネル更新と再起動をすぐに実施できない場合は、次の対策で攻撃経路を限定します。

  • ksmbdを使用していない場合は無効化または停止する
  • Azure Network Security Groupやホスト側ファイアウォールでTCP 445番を制限する
  • SMB接続元を管理されたプライベートネットワークや許可済みIPに限定する
  • 不要なSMB共有を停止する
  • カーネルクラッシュ、異常再起動、SMB関連エラーを監視する
  • 修正版適用までの期限と担当者を明確にする

公式CVEレコードでは、認証済みSMBクライアントから問題が再現されています。そのため、インターネットからTCP 445番を遮断するだけでなく、内部ネットワークの接続元や認証アカウントも確認する必要があります。

これらは攻撃可能性を下げるための一時的な対策であり、カーネル更新の代替にはなりません。

対応時に失敗しやすいポイント

失敗例問題点正しい対応
RPMの更新だけで完了とする古いカーネルが稼働したままになる再起動後にuname -rを確認
uname -rだけを見る修正版が導入済みか判断できないrpm -q kernelも併用
上流Linuxの版だけで判定するAzure Linuxのバックポートを見落とすMSRCのFirstFixedを基準にする
ksmbdが未使用なので更新しない将来の有効化や構成変更で露出する該当パッケージは計画的に更新
標準kernelの修正版を別系列へ流用するHWE、RT、MSHVなどでは版体系が異なる使用中のパッケージ名を先に確認
全台を同時に更新する起動障害時にサービス全体へ影響する検証環境や先行ノードから適用
TCP 445番の遮断だけで終了する内部ネットワークからの経路が残る緩和策と更新を並行して進める

CVE-2026-64437への対応まとめ

CVE-2026-64437は、Azure Linux 3.0のksmbdで、SMB2_CLOSE後のSMB2_CANCELによって解放済みのfile_lockが再利用される脆弱性です。

標準kernelパッケージの修正版は、MSRCがFirstFixedとして示す6.6.144.1-1です。対応では、次の順序を守ることが重要です。

  1. cat /etc/os-releaseでAzure Linux 3.0か確認する
  2. rpm -q kernelでインストール済みパッケージを確認する
  3. uname -rで現在稼働中のカーネルを確認する
  4. 修正版未満ならtdnfまたは管理されたノードイメージ更新を実行する
  5. 再起動後、uname -rで修正版が稼働していることを確認する
  6. SMB共有やアプリケーションの動作確認を行う

まず対象サーバーでuname -rとrpm -q kernelを実行し、「修正版がインストールされているか」と「その修正版で実際に起動しているか」の2点を確認してください。

Linux
SMB Azure Linux ksmbd カーネル更新 CVE-2026-64437

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次