MENU

CVE-2026-64380対策：Azure Linux 3.0の修正版と確認・更新手順

Azure

Microsoft Azure Linux 3.0で標準のkernelパッケージを使用しており、実行中のカーネルが6.6.144.1-1.azl3より古い場合は、CVE-2026-64380への対応として修正版以降へ更新してください。MSRCがAzure Linux 3.0向けのFirstFixedとして示しているのは「azl3 kernel 6.6.144.1-1」です。

重要なのは、更新パッケージをインストールするだけで終わらせないことです。カーネル更新後に再起動し、uname -rで実際に修正版が動いていることまで確認する必要があります。CVSS基本値は8.2の「High」で、SMBクライアントが受信した不正なPOSIX SIDを解析する際の長さ検証に問題があります。(Microsoft Security Response Center)

目次

CVE-2026-64380の概要と修正版

CVE-2026-64380は、LinuxカーネルのSMBクライアントにあるPOSIX SIDの長さ検証不備です。Azure Linux 3.0では、Microsoftが提供する修正済みカーネルへ更新することで対処します。

項目内容
CVE番号CVE-2026-64380
対象Microsoft Azure Linux 3.0
対象コンポーネントLinuxカーネルのSMBクライアント
問題の内容POSIX SIDを解析する際の長さ検証不備
CVSS基本値8.2／High
CVSSベクターCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
MSRCのFirstFixedazl3 kernel 6.6.144.1-1
RPM上の表記例kernel-6.6.144.1-1.azl3.x86_64
CWEMSRCでは掲載なし
必要な対応カーネル更新、再起動、実行中バージョンの再確認

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

FirstFixedは「最初に修正された版」を示すものです。運用環境を必ずこの版に固定するという意味ではありません。より新しいMicrosoft提供のセキュリティ更新が利用できる場合は、原則として最新のサポート済みカーネルを適用します。

POSIX SIDの長さ検証不備とは

問題が起きていた処理

脆弱性があるのは、Linuxカーネルの次のSMBクライアント関連ファイルです。

fs/smb/client/smb2pdu.c

問題の関数posix_info_sid_size()は、受信したSIDデータの2バイト目に当たるsid[1]を読み取り、サブオーソリティ数を取得します。

ところが、従来の境界チェックでは、バッファに残っているデータが1バイトしかない場合でも処理を続行できました。sid[1]を読むには最低2バイトが必要なため、切り詰められたPOSIX SIDを受信すると、バッファ末尾を越えて参照する可能性があります。

修正後は、sid[1]を読む前に2バイト以上残っていることを確認し、不完全なPOSIX SIDを安全に拒否します。(GitHub)

CVSS 8.2から読み取れる影響

CVSSベクターは次のとおりです。

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H

実務上、特に確認すべき点は次の3つです。

  • ネットワーク経由で到達可能と評価されている
  • 攻撃条件の複雑さが低く、事前の権限や利用者操作を必要としない
  • 可用性への影響が「High」、機密性への影響が「Low」と評価されている

一方、完全性への影響は「None」です。公開されているCVE情報だけから、リモートコード実行が可能な脆弱性と断定することはできません。「CVSS 8.2だからRCE」と短絡せず、SMBクライアントの異常終了やカーネルへの影響を中心に評価するのが適切です。(GitHub)

また、MSRCでCWEが掲載されていないことは、脆弱性が存在しない、または危険度が低いことを意味しません。単にCWEによる弱点分類が掲載されていないという意味です。

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

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

  1. OSがAzure Linux 3.0か
  2. 修正版パッケージがインストールされているか
  3. 修正版カーネルで現在起動しているか

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

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

cat /etc/os-release

対象環境では、次のような情報が表示されます。

NAME="Microsoft Azure Linux"
VERSION_ID="3.0"
PRETTY_NAME="Microsoft Azure Linux 3.0"

MicrosoftのAzure Linuxリポジトリでも、6.6.144.1-1.azl3がAzure Linux 3.0上で動作することがx86環境のスモークテストで確認されています。(GitHub)

Azure Linux 2.0や4.0、Ubuntu、Red Hat Enterprise Linuxなどは、今回のMSRCに記載されたAzure Linux 3.0向けFirstFixedをそのまま判定基準にはできません。それぞれのディストリビューションや製品のセキュリティ情報を確認してください。

実行中のカーネルを確認する

現在動いているカーネルは、次のコマンドで確認できます。

uname -r

修正版で起動している場合の表示例は次のとおりです。

6.6.144.1-1.azl3

少なくとも、標準のAzure Linux 3.0カーネルでは、6.6.144.1-1.azl3またはMicrosoftが提供するそれ以降の修正版で起動していることを確認します。

CPUアーキテクチャは次のコマンドで確認できます。

uname -m

一般的な出力は次のいずれかです。

x86_64
aarch64

インストール済みパッケージを確認する

標準カーネルのインストール状況は、次のコマンドで確認します。

rpm -q kernel

カーネル関連パッケージをまとめて確認したい場合は、次のように実行します。

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

パッケージ名、バージョン、リリース、アーキテクチャを明示したい場合は、次のコマンドが便利です。

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

修正版の表示例は次のとおりです。

kernel-6.6.144.1-1.azl3.x86_64

確認結果ごとの対応

確認結果判定必要な対応
Azure Linux 3.0で、実行中カーネルが6.6.144.1-1.azl3より古い修正済みと確認できないカーネルを更新して再起動
修正版パッケージはインストール済みだが、uname -rは古い更新未反映再起動して修正版で起動
uname -rが6.6.144.1-1.azl3またはそれ以降標準カーネルでは修正済み他のVMやノードも確認
Azure Linux 3.0ではない今回の製品判定外対象OSの公式情報を確認
kernel-hweや独自ビルドなどを使用単純比較できない使用パッケージ別の修正情報を確認

特に注意したいのは、rpm -q kernelだけでは不十分なことです。修正版がインストールされていても、再起動前は古いカーネルがメモリ上で動き続けます。必ずuname -rも確認してください。

SMBクライアントを使用しているか調べる

この問題はSMBクライアント側の解析処理にあります。SMBまたはCIFS共有を利用しているAzure Linuxホストは、対応の優先度を高くします。

現在マウントされているCIFS共有は、次のコマンドで確認できます。

findmnt -t cifs

/etc/fstabに自動マウント設定があるか調べるには、次のコマンドを実行します。

grep -Ev '^[[:space:]]*(#|$)' /etc/fstab | grep -w cifs

次のような利用形態も確認してください。

  • 業務アプリケーションがSMB共有をマウントしている
  • バックアップ処理がファイルサーバーへ接続している
  • 起動時やバッチ処理時だけCIFSマウントを実行する
  • Azure FilesなどのSMB共有をLinuxから使用している
  • スクリプトやsystemdユニットがmount.cifsを呼び出している

ただし、現在のfindmnt結果が空でも「脆弱性の影響を受けない」とは判断できません。将来SMB接続が行われる可能性や、特定時間だけ実行されるジョブがあるためです。SMB利用状況は対応順序を決める材料であり、カーネル更新の代替にはなりません。

Azure Linux 3.0を修正版へ更新する手順

Azure Linux 3.0では、従来のAzure Linuxリリースで使用されているtdnfでパッケージを更新します。MicrosoftのAzure Linux 4.0向け資料でも、以前のAzure Linuxリリースではtdnfが使われていたことが説明されています。(Microsoft Learn)

更新前に確認すること

本番環境では、更新前に次の準備を行います。

  • VMやイメージの復旧手段を確保する
  • カーネル更新後の再起動時間を確保する
  • 冗長構成では一台ずつ更新する
  • SSHで接続できなくなった場合に備え、コンソール接続手段を確認する
  • DKMSや独自カーネルモジュールを使用している場合は互換性を確認する
  • 稼働中のカーネル版とパッケージ一覧を記録する

カーネル変更後にLinux VMが起動できなくなるケースもあるため、特に独自ドライバーや外部モジュールを使う環境では、検証環境で先に起動確認を行うことが重要です。

利用可能な更新を確認する

最初にリポジトリ情報を更新します。

sudo tdnf makecache

続いて、カーネル更新が提供されているか確認します。

sudo tdnf check-update kernel

リポジトリに6.6.144.1-1より新しいカーネルがある場合は、FirstFixedへ戻すのではなく、通常はその新しいサポート済みパッケージを適用します。

カーネルを更新する

カーネルを対象に更新する場合は、次のコマンドを実行します。

sudo tdnf update -y kernel

変更管理上問題がなければ、関連するセキュリティ修正をまとめて取り込むため、システム全体を更新する方法もあります。

sudo tdnf update -y

更新後、修正版がインストールされたことを確認します。

rpm -q kernel

期待する表示例は次のとおりです。

kernel-6.6.144.1-1.azl3.x86_64

Arm64環境では末尾がaarch64になります。公式リポジトリには両アーキテクチャ向けの修正版パッケージが掲載されています。(Microsoft Packages)

OSを再起動する

カーネル更新を実行しただけでは、実行中のカーネルは切り替わりません。メンテナンス可能なタイミングで再起動します。

sudo reboot

再起動後、再接続して実行中カーネルを確認します。

uname -r

次の版またはそれ以降が表示されていることを確認してください。

6.6.144.1-1.azl3

併せて、インストール済みパッケージも再確認します。

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

上流Linuxの6.6.145とAzure Linuxの6.6.144.1-1が異なる理由

公式CVEレコードでは、上流Linuxカーネルの6.6系について、6.6.145が修正済みの版として記録されています。一方、MSRCがAzure Linux 3.0向けに示しているFirstFixedは6.6.144.1-1です。(GitHub)

この違いを見て、「6.6.144.1は6.6.145より古いので未修正」と判断してはいけません。

Azure Linuxでは、安定性を保つため、カーネルなどの主要コンポーネントへ修正をバックポートし、大きなバージョン変更を抑える方針が示されています。上流Linuxの版番号と、Azure LinuxのRPMリリース番号は別の基準で管理されるためです。(Microsoft Learn)

Azure Linux 3.0の判定では、次の優先順位で確認します。

  1. MSRCが製品別に掲載するFirstFixed
  2. Microsoft公式リポジトリのパッケージ版
  3. 実行中のAzure Linuxカーネル版
  4. 上流Linuxの修正情報

上流の数字だけで判定せず、6.6.144.1-1.azl3のようにAzure Linux固有のリリース部分まで含めて比較することが重要です。

Azure VM、VM Scale Sets、AKSで対応方法が異なる

単体のAzure VM

管理者がOSを直接管理しているAzure VMでは、tdnfでカーネルを更新し、再起動後にuname -rを確認します。

複数台構成では、すべてを同時に再起動せず、ロードバランサーやクラスタから一台ずつ切り離して更新します。

Virtual Machine Scale Sets

イメージを基準にインスタンスを展開している場合、個々のVMだけを手作業で更新すると、スケールアウトや再作成時に古いカーネルへ戻る可能性があります。

次の両方を実施します。

  • 稼働中インスタンスを修正版へ更新する
  • 元になるカスタムイメージやイメージ定義も更新する

更新済みイメージを作成した後、ローリング方式でインスタンスを置き換え、全台の実行中カーネルを確認します。

AKSのAzure Linuxノード

AKSでAzure LinuxをノードOSとして使用している場合は、アプリケーションコンテナ内でkernelパッケージを更新するのではなく、ノード側のカーネルを更新する必要があります。

通常のコンテナはホスト側のカーネルを共有します。そのため、コンテナイメージ内のユーザー空間パッケージを更新しても、AKSノードで実行されているカーネルは切り替わりません。(Microsoft Learn)

AKSでは、Microsoftが案内するノードイメージアップグレードを利用して、対象ノードプールのイメージを更新します。(Microsoft Learn)

更新後は、一部のノードだけが古いイメージのまま残っていないかを確認してください。クラスタ単位ではなく、ノード単位でカーネル版やノードイメージ版を確認する必要があります。

環境主な対応
単体Azure VMtdnfで更新し、VMを再起動
冗長化されたAzure VM一台ずつ切り離して更新・再起動
VM Scale Sets元イメージを更新し、インスタンスをローリング置換
AKSAzure Linuxノードイメージを更新
アプリケーションコンテナコンテナではなくホストまたはAKSノードを更新
カスタムイメージゴールデンイメージを更新して再展開

更新時に失敗しやすいポイント

修正版をインストールしただけで完了にする

最も多い見落としは、rpm -q kernelで修正版が表示された時点で作業を完了することです。

確認すべきなのは、次の両方です。

rpm -q kernel
uname -r

前者はインストール済みパッケージ、後者は現在動いているカーネルを示します。両者が修正版以降になって初めて、更新が実行環境へ反映されたと判断できます。

上流Linuxの版番号だけで比較する

Azure Linuxではセキュリティ修正がバックポートされる場合があります。6.6.144.1と6.6.145の数字だけを比べず、MSRCが示す製品別FirstFixedとRPMのリリース番号を基準にしてください。

FirstFixedへダウングレードする

すでに6.6.144.1-1より新しいMicrosoft提供カーネルを使用している場合、FirstFixedへ戻す必要はありません。

FirstFixedは最低限の修正境界です。新しいサポート済みカーネルには、CVE-2026-64380以外の修正も含まれる可能性があるため、特別な互換性要件がなければ最新パッケージを維持します。

一台だけ更新して終了する

VM Scale SetsやAKSノードプールでは、古いカーネルのノードが一台でも残っていれば、ワークロードがそのノードへ移動する可能性があります。

インベントリを作成し、次の単位で更新状況を確認します。

  • サブスクリプション
  • リソースグループ
  • VM
  • VM Scale Setsのインスタンス
  • AKSクラスタ
  • AKSノードプール
  • 個別ノード
  • カスタムイメージ

SMBを今使っていないので更新しない

現在SMB共有がマウントされていなくても、定期バッチ、障害時の復旧処理、バックアップ、起動時マウントなどで後からSMBクライアントが使われることがあります。

SMBの利用有無はパッチ適用の優先順位を決める材料にはなりますが、Azure Linux 3.0のカーネルを古いまま維持する根拠にはなりません。

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

業務上の理由で直ちに再起動できない場合は、メンテナンスまでの間、次のようなリスク低減策を検討します。

  • 不要なSMB/CIFSマウントを一時停止する
  • SMB接続先を業務上必要なサーバーに限定する
  • 信頼できないネットワーク上のSMBサーバーへ接続しない
  • SMBを使用するバッチや自動マウント処理を確認する
  • カーネルエラーや異常終了のログを監視する
  • 再起動日時と対象ホストを明確にした更新計画を作成する

カーネルログは次のように確認できます。

journalctl -k -p err..alert

これらはあくまで暫定的なリスク低減策です。CVE-2026-64380を修正済みと判断するには、修正版カーネルへ更新し、そのカーネルで再起動する必要があります。

更新結果を記録する方法

脆弱性対応の証跡として、更新前後に次の情報を保存しておくと、監査やインシデント対応に役立ちます。

date -Is
cat /etc/os-release
uname -m
uname -r
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
findmnt -t cifs

複数台を管理している場合は、次の項目を一覧化します。

記録項目例
ホスト名azl-app-01
環境本番／検証
OSMicrosoft Azure Linux 3.0
CPUx86_64／aarch64
更新前カーネル6.6.143.1-1.azl3
更新後カーネル6.6.144.1-1.azl3以降
SMB利用あり／なし／調査中
更新日時ISO 8601形式
再起動確認完了／未完了
担当者管理者名またはチーム名

CVE-2026-64380対応で実施すべきこと

CVE-2026-64380への対応では、最初にAzure Linux 3.0かどうかを確認し、次にインストール済みカーネルと実行中カーネルを分けて調べます。

標準カーネルが6.6.144.1-1.azl3より古い場合は、Microsoftが提供する修正版以降へ更新してください。更新後は必ず再起動し、uname -rで実行中の版を確認します。

単体VMだけでなく、VM Scale Setsの元イメージ、AKSの全ノードプール、カスタムイメージも確認することが重要です。まず次のコマンドを実行し、対象判定を始めてください。

cat /etc/os-release
uname -r
rpm -q kernel
findmnt -t cifs

パッケージ更新、再起動、実行中バージョンの確認までを一連の作業として完了させることが、CVE-2026-64380対策の要点です。

Azure
カーネル SMB 脆弱性対策 Azure Linux 3.0 CVE-2026-64380

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次