MENU

CVE-2026-64448対策：Azure Linux 3.0のSMB応答検証不備と修正版

Linux

CVE-2026-64448への対策は、Azure Linux 3.0の標準kernelパッケージを6.6.144.1-1以上へ更新し、再起動後に実行中のカーネルを確認することです。

Microsoft Security Response Center（MSRC）は、修正が初めて含まれる版としてazl3 kernel 6.6.144.1-1 on Azure Linux 3.0をFirstFixedに掲載しています。MSRC上のCVSSスコアは8.1で、CWEは掲載されていません。パッケージをインストールしただけでは古いカーネルが動き続けるため、更新後の再起動まで必要です。(Microsoft Security Response Center)

この脆弱性はSMBサーバー機能ではなく、LinuxカーネルのSMBクライアント処理に存在します。そのため、受信方向のTCP 445番ポートを閉じているサーバーでも、NASやWindowsファイルサーバーへCIFSマウントしている場合は確認が必要です。

目次

CVE-2026-64448の概要とAzure Linux 3.0向け修正版

項目内容
CVE番号CVE-2026-64448
対象Microsoft Azure Linux 3.0
該当コンポーネントLinuxカーネルのSMBクライアント処理
問題SMB応答データ長の検証不備
想定される結果受信バッファ終端を越える読み取り
到達する処理SMBのNEGOTIATE、SESSION_SETUP
MSRCのCVSS8.1
CWEMSRCでは未掲載
FirstFixedazl3 kernel 6.6.144.1-1 on Azure Linux 3.0
必要な対応カーネル更新、再起動、実行中バージョンの再確認

公開されたLinuxカーネルの修正内容では、smb2_check_message()がSMB応答の長さを検査する際、本来はデータ領域がない応答に限って認めるべき1バイトの差を、データ領域がある応答にも適用していたことが説明されています。(GitHub)

SMB応答データ長の検証不備とは

互換性のための「1バイト例外」が広く適用されていた

SMBクライアントは、サーバーから届いた応答について、ヘッダーやデータ領域を基にメッセージ全体の長さを計算します。

従来の処理には、データ領域がない一部のサーバー応答との互換性を保つため、次のような例外がありました。

  • カーネルが計算した長さ
  • 実際に受信した長さ

この2つに1バイトの差があっても、特定のケースでは正常な応答として受け入れるというものです。

問題は、この例外がデータ領域の有無を十分に区別せず適用されていたことです。

データ領域がある応答で長さが1バイト過大に申告されると、カーネルは実際に受信したバッファより先までデータがあると判断します。その後のデコーダーが受信バッファの終端を越えて読み取る可能性があります。

セッション確立前の処理で到達する

問題の処理は、SMB接続の次の段階で到達できます。

  • NEGOTIATE：SMBのバージョンや機能を調整する処理
  • SESSION_SETUP：認証やセッション確立を行う処理

つまり、ファイル共有への接続が完全に成立した後だけでなく、接続交渉や認証の途中でも影響を受ける可能性があります。

公開された検証結果では、非準拠のSMBサーバーにマウントした際、SPNEGOとNTLMSSPに関係するデコーダーでKASANによる範囲外読み取りが確認されています。修正では、1バイト差の許容を「データ領域がない応答」に限定しています。(GitHub)

RCEと断定しない

公開情報で直接確認されている問題は、受信バッファ外の読み取りです。したがって、CVE-2026-64448を根拠なく「リモートコード実行の脆弱性」と説明するのは適切ではありません。

一方で、範囲外読み取りは異常終了や可用性低下、意図しないメモリ参照につながる可能性があります。MSRCのCVSSが8.1であることも踏まえ、SMBを利用している環境では優先度を上げて対応すべき脆弱性です。(Microsoft Security Response Center)

影響を受けるAzure Linux 3.0環境の判断方法

次の3点を順番に確認します。

  1. OSがAzure Linux 3.0か
  2. 実行中のカーネルが修正版より前か
  3. SMBクライアントを使用しているか

Azure Linux 3.0であることを確認する

次のコマンドを実行します。

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

VERSION_ID="3.0"であることを確認してください。

別のLinuxディストリビューションやAzure Linuxの別バージョンでは、MSRCに掲載された6.6.144.1-1をそのまま判定基準にしてはいけません。ディストリビューションごとにバックポート方法やパッケージ番号が異なるためです。

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

実行中のカーネルは、次のコマンドで確認できます。

uname -r

インストール済みの標準カーネルパッケージも確認します。

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

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

kernel 6.6.143.1-1.azl3.x86_64

この例はFirstFixedの6.6.144.1-1より前なので、更新対象です。

修正済みの実行例は次のようになります。

6.6.144.1-1.azl3.x86_64

アーキテクチャによって末尾は異なりますが、標準kernelパッケージでは6.6.144.1-1以上が判断基準です。MicrosoftのAzure Linux 3.0向け公式パッケージリポジトリでも、kernel-6.6.144.1-1.azl3が公開されています。(Microsoft Packages)

「インストール済み」と「実行中」を混同しない

次の状態では、対応は完了していません。

rpm -q kernel
→ kernel-6.6.144.1-1.azl3.x86_64

uname -r
→ 6.6.143.1-1.azl3.x86_64

修正版パッケージはインストールされていますが、メモリ上では古いカーネルが動いています。再起動し、新しいカーネルで起動する必要があります。

カーネル更新では、rpm -q kernelだけでなくuname -rを最終判定に使うことが重要です。

SMBクライアントの利用状況を確認する

現在マウントされているCIFS共有を確認します。

findmnt -t cifs

永続的なマウント設定やautofs設定を検索します。

grep -R -nE '\bcifs\b' /etc/fstab /etc/auto.* 2>/dev/null

CIFSカーネルモジュールが読み込まれているか確認します。

lsmod | grep '^cifs'

次のような環境は、特に優先して確認してください。

  • Windowsファイルサーバーをマウントしている
  • NASをCIFSでマウントしている
  • Azure FilesのSMB共有を利用している
  • バックアップ処理で一時的にSMB共有をマウントする
  • autofsでSMB共有を自動マウントする
  • 利用者が指定した共有先をmount.cifsで接続する
  • VPNや閉域網を通して外部組織のSMBサーバーへ接続する

findmnt -t cifsの結果が空でも、現在マウントされていないだけの場合があります。/etc/fstab、autofs、バッチ処理、構成管理ツールも確認してください。

対応が必要かを判断する早見表

確認結果判断対応
実行中カーネルが6.6.144.1-1より前で、SMBを利用中影響を受ける可能性が高い優先して更新・再起動
修正版がインストール済みだがuname -rが旧版古いコードが実行中再起動する
実行中カーネルが6.6.144.1-1以上本CVEの修正版基準を満たすSMB接続とログを確認
SMBを現在利用していない直接的な到達可能性は低い将来の利用に備えて更新
kernel-hweやkernel-mshvなど別系統を使用標準kernelの番号だけでは判定不可使用中パッケージ向けの修正情報を確認
AKSのAzure Linuxノードノード単体の手動更新は非推奨AKSのノードイメージを更新

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

更新前にメンテナンス条件を確認する

カーネル更新では再起動が発生します。実施前に次を確認してください。

  • VMやアプリケーションのメンテナンス時間
  • バックアップや復旧手段
  • Azure Serial Consoleなどのコンソール接続手段
  • /bootと/boot/efiの空き容量
  • NVIDIA、Lustre、監視製品などのカーネルモジュール
  • 再起動後に必要となるSMB共有の接続情報
  • 負荷分散や冗長化構成の切り替え手順

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

df -h /boot /boot/efi

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

rpm -qa | grep -E '^(kernel|dkms|nvidia|lustre)' | sort -V

外部カーネルモジュールを利用している環境では、新しいカーネルへの対応状況を事前に確認してください。カーネル自体の更新に成功しても、再起動後にドライバーやファイルシステム用モジュールが読み込めない場合があります。

標準kernelパッケージを更新する

Azure Linux 3.0の標準カーネルは、次のコマンドで更新できます。

sudo tdnf upgrade kernel

表示される更新対象とバージョンを確認し、処理を完了します。

パッケージ情報が古い、または修正版が見つからない場合は、キャッシュを更新してから再実行します。

sudo tdnf clean all
sudo tdnf makecache
sudo tdnf upgrade kernel

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

更新後に再起動する

sudo reboot

カーネルパッケージの更新だけでは、実行中のカーネルは切り替わりません。再起動を延期する場合は、その間も古いカーネルが稼働していることを運用記録に残してください。

再起動後に修正済みカーネルを確認する

再接続後、まず実行中のバージョンを確認します。

uname -r

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

6.6.144.1-1.azl3.x86_64

または、これより新しいAzure Linux 3.0向けカーネルです。

インストール済みパッケージも確認します。

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

rpmの結果が新しくても、uname -rが古い場合は、次の可能性があります。

  • 再起動が完了していない
  • GRUBで古いカーネルを選択した
  • 新しいカーネルの起動に失敗して旧版へ戻った
  • 更新対象とは異なるカーネル系統を使用している

OSとSMB接続の正常性を確認する

失敗したsystemdユニットを確認します。

systemctl --failed

今回の起動で警告以上のログを確認します。

sudo journalctl -b -p warning --no-pager

SMB共有のマウント状態も確認します。

findmnt -t cifs

運用環境では、バージョン確認だけでなく次のテストも行ってください。

  • SMB共有への再接続
  • ファイルの読み取りと書き込み
  • アプリケーションからの共有フォルダー利用
  • KerberosまたはNTLM認証
  • 自動マウント処理
  • バックアップジョブ
  • 再起動後の監視エージェントやドライバー

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

Azure Kubernetes Service（AKS）のAzure Linuxノードでは、各ノードに接続してtdnf upgrade kernelを実行する方法を恒久対策にしないでください。

AKSノードは再イメージ化やスケール操作で置き換わるため、個別に加えた変更が失われる可能性があります。AKSが提供するノードイメージ更新またはNode OS自動更新チャネルを利用します。

利用可能なノードイメージを確認する

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

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

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

特定のノードプールを更新する

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

AKSでは、Kubernetesのバージョンを変更せずにノードイメージだけを更新できます。Microsoftはノードイメージの自動更新チャネルも推奨しており、NodeImageやSecurityPatchを利用してメンテナンス時間内にOSのセキュリティ更新を適用できます。(Microsoft Learn)

ノードイメージはリージョンごとに展開時期が異なる場合があります。「最新イメージへ更新した」という事実だけで判断せず、対象イメージのリリース情報と更新後のカーネルを確認してください。

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

修正版への更新が根本対策です。メンテナンス時間を確保できない場合は、それまでの一時措置として次を検討します。

一時措置目的
不要なCIFSマウントを解除する脆弱な処理へ到達する機会を減らす
/etc/fstabやautofsの自動マウントを停止する再起動やアクセス時の自動接続を防ぐ
送信方向のTCP 445番を許可リスト化する不明なSMBサーバーへの接続を防ぐ
接続先を管理下のSMBサーバーに限定する細工された応答を受信する可能性を下げる
利用者が入力した共有先を直接マウントしない任意のSMB接続先を指定される経路をなくす
CIFSとカーネルのエラーログを監視する異常終了や接続失敗を早期検知する

この脆弱性はクライアント処理にあるため、受信方向の445番ポートを閉じるだけでは十分ではありません。Azure Linux側からSMBサーバーへ接続する送信経路を確認する必要があります。

対応時に起きやすい失敗

cifs-utilsだけを更新する

mount.cifsはSMB共有をマウントするためのユーザー空間ツールですが、今回の問題が存在するのはLinuxカーネル内のSMBクライアント処理です。

したがって、cifs-utilsだけを更新してもCVE-2026-64448の修正にはなりません。修正版のカーネルが必要です。(GitHub)

パッケージ更新後に再起動しない

最も起きやすい失敗です。

次の2つを必ず両方確認してください。

rpm -q kernel
uname -r

修正版がインストールされていても、uname -rが旧版なら対応は未完了です。

上流カーネルの番号だけで判断する

Azure Linuxのカーネルには、上流Linuxの修正がバックポートされることがあります。

そのため、単純に「上流では別のカーネル番号で修正されたから、Azure Linuxの6.6.144.1-1では未修正」と判断してはいけません。Azure Linux 3.0では、MSRCが示すFirstFixedを優先して判定します。(Microsoft Security Response Center)

kernel-hweやkernel-mshvに標準kernelの番号を当てはめる

Azure Linux環境では、標準kernel以外のカーネルが使われる場合があります。

使用中のカーネルパッケージを確認するには、次のコマンドが役立ちます。

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

kernel-hwe、kernel-64k、kernel-mshv、リアルタイムカーネルなどを使用している場合は、標準kernelのFirstFixedだけで判定せず、それぞれのパッケージに対するMSRC情報やリリース情報を確認してください。

AKSノードを1台ずつ手動更新する

AKSのノードへ直接変更を加えても、ノードの再イメージ化で元に戻る可能性があります。

AKSでは、ノードプールのイメージ更新やNode OS自動更新チャネルを使用し、Pod Disruption Budget、サージ設定、メンテナンス時間も含めて更新を管理します。

よくある疑問

6.6.144.1-1と完全に一致していなければならない？

完全一致である必要はありません。

MSRCのFirstFixedは「修正が初めて含まれた版」を示します。標準kernelパッケージが6.6.144.1-1、またはそれより新しいAzure Linux 3.0向け正式版であれば、修正版基準を満たします。

SMB共有を使っていなければ更新しなくてもよい？

現在SMBクライアントを使用していなければ、直ちに問題の処理へ到達する可能性は下がります。

ただし、将来の設定変更、バックアップ処理、一時的なマウント、障害対応作業でSMBを利用する可能性があります。脆弱なカーネルを残す理由にはならないため、通常のセキュリティ更新計画に組み込んでください。

CWEが掲載されていないのは影響が不明という意味？

CWE未掲載は、MSRCの該当欄に弱点分類が登録されていないという意味です。

脆弱性や修正版が存在しないという意味ではありません。対応判断では、CWEの有無よりも対象製品、FirstFixed、技術的な到達条件を重視します。

カーネル更新後の再起動は必須？

実行中の脆弱なカーネルを修正版へ切り替えるには、通常は再起動が必要です。

再起動前にrpm -q kernelで修正版が確認できても、uname -rが旧版であれば脆弱なコードが引き続き動作しています。

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

Azure Linux 3.0を運用している場合は、次の順番で対応してください。

  1. /etc/os-releaseでAzure Linux 3.0か確認する
  2. uname -rで実行中のカーネルを確認する
  3. rpm -q kernelでインストール済みパッケージを確認する
  4. CIFSマウント、/etc/fstab、autofsの利用状況を確認する
  5. 標準kernelが6.6.144.1-1より前なら更新する
  6. システムを再起動する
  7. uname -rが6.6.144.1-1以上になったことを確認する
  8. SMB共有、アプリケーション、外部カーネルモジュールをテストする
  9. AKSではノード単体ではなくノードイメージを更新する

最終的な完了条件は、修正版パッケージのインストールではなく、修正済みカーネルが実際に動作していることです。

Linux
SMB Azure Linux 3.0 Linuxカーネル CVE-2026-64448

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次