CVE-2026-64304は、Microsoft Azure Linux 3.0のLinuxカーネルに含まれるIntel QATドライバーで、RSA CRT構成要素の長さを十分に検証していなかった脆弱性です。細工されたRSA秘密鍵が処理されると、DMAバッファの範囲外へデータが書き込まれ、カーネルメモリが破損する可能性があります。
MSRCがAzure Linux 3.0向けの最初の修正版として示しているのは、azl3 kernel 6.6.144.1-1 on Azure Linux 3.0です。標準のkernelパッケージを利用しており、実行中のカーネルがこれより古い場合は、修正版またはそれ以降へ更新し、必ず再起動してください。修正版をインストールしただけでは、古いカーネルが動き続けていることがあります。 (Microsoft Security Response Center)
CVE-2026-64304の概要
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-64304 |
| 対象 | Microsoft Azure Linux 3.0 |
| 影響を受ける部分 | LinuxカーネルのIntel QAT暗号ドライバー |
| 関連ファイル | drivers/crypto/intel/qat/qat_common/qat_asym_algs.c |
| 処理 | RSA CRTを使用する秘密鍵処理 |
| 技術的な問題 | RSA CRT構成要素の長さ検証不足 |
| 想定される結果 | DMAバッファ外への書き込み、カーネルメモリ破損 |
| CVSS v3.1 | 7.8、High |
| CVSSベクター | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| CWE | 公開情報では未掲載 |
| Azure Linux 3.0のFirstFixed | kernel 6.6.144.1-1 |
| 必要な対応 | カーネル更新、再起動、稼働版の再確認 |
NVDに掲載された説明では、RSA CRTの5つの構成要素であるp、q、dp、dq、qinvの長さが問題になります。公開時点ではNVDのWeakness Enumeration欄にもCWEは登録されていません。 (NVD)
Intel QATのRSA CRT処理で何が起きるのか
Intel QATは、暗号化や圧縮などの処理をハードウェアで高速化するための技術です。今回のCVE-2026-64304は、QATドライバーがRSA秘密鍵をCRT方式で扱う処理にあります。
RSA CRTでは、秘密鍵による署名や復号を高速化するため、次のような値を利用します。
p、q：RSAで使用する2つの素数dp、dq：秘密指数をpとqに対応させた値qinv：CRT計算に使用する逆元
Linuxカーネルの汎用RSAキーパーサーは、これらの値をRSAモジュラスのサイズ以内に制限していました。一方、QAT側のqat_rsa_setkey_crt()は、それぞれの値を格納するために鍵サイズの半分に相当するDMAバッファを確保します。
つまり、検証に使われる上限と、実際に確保されるバッファの大きさが一致していませんでした。
問題となるオフセット計算は、概念的には次の形です。
dst + half_key_sz - lenlenがhalf_key_szより大きいと減算がアンダーフローし、その後のmemcpy()がDMAバッファの外側へ書き込む可能性があります。修正では、5つのCRT構成要素それぞれについてlen > half_key_szを検査し、大きすぎる場合はCRTを使わない処理へフォールバックするよう変更されています。 (NVD)
CVSS 7.8をどう判断するべきか
CVE-2026-64304のCVSSベクターは、次のように読み取れます。
| 指標 | 値 | 運用上の意味 |
|---|---|---|
| 攻撃元区分 | AV:L | CVSS上はローカルアクセスが必要 |
| 攻撃条件 | AC:L | 攻撃の複雑さは低い |
| 必要権限 | PR:L | 低い権限を持つ利用者やプロセスから到達する可能性 |
| 利用者操作 | UI:N | 別の利用者による操作は不要 |
| スコープ | S:U | 影響範囲は同一のセキュリティ境界内 |
| 機密性 | C:H | 高い影響 |
| 完全性 | I:H | 高い影響 |
| 可用性 | A:H | 高い影響 |
インターネットから認証なしで直接攻撃されるタイプとして評価されているわけではありません。しかし、いったんホスト上で低権限のコードを実行できる状態になると、低い複雑さでカーネルメモリ破損につながる可能性があるため、軽視はできません。 (NVD)
特に、次の環境は更新優先度を上げるべきです。
| 優先度 | 環境の例 | 判断理由 |
|---|---|---|
| 高 | Intel QATを利用し、信頼できない利用者やワークロードが存在する | 脆弱な処理とローカル攻撃者の両方が存在する可能性 |
| 高 | 外部から受け取ったRSA秘密鍵をインポートまたは処理する | 異常なCRT構成要素が処理経路へ入る可能性 |
| 高 | 複数の利用者やワークロードがカーネルを共有する | 1つの侵害がホスト全体へ影響する可能性 |
| 中 | QATを利用しているが、管理者が制御した鍵だけを扱う | 到達可能性は限定されるが、カーネルメモリ破損の影響は大きい |
| 通常 | QATを使用していないことが確認できている | 直近の到達可能性は低いが、脆弱なカーネルは更新対象 |
QATを現在利用していないことは、修正を不要とする理由にはなりません。将来の構成変更、PCIデバイスの割り当て、モジュールの読み込みによって、脆弱な処理が利用可能になることがあるためです。
Azure Linux 3.0のカーネル版を確認する
OSがAzure Linux 3.0か確認する
最初に、対象ホストのOS情報を確認します。
cat /etc/os-releaseVERSION_IDやPRETTY_NAMEを確認し、Azure Linux 3.0であることを確かめてください。別のディストリビューションやAzure Linuxの別メジャーバージョンには、そのベンダーや製品向けの修正版情報を適用します。
現在動作しているカーネルを確認する
uname -r標準のAzure Linux 3.0カーネルでは、次のような形式で表示されます。
6.6.143.1-1.azl3.x86_64MSRCが示す最初の修正版に対応する表示例は、次のとおりです。
6.6.144.1-1.azl3.x86_64x86_64などの末尾はアーキテクチャによって異なります。重要なのは、Azure Linux 3.0の標準kernelパッケージについて、バージョンとリリースを含めて6.6.144.1-1.azl3以上になっていることです。Microsoftのパッケージリポジトリでも、kernel-6.6.144.1-1.azl3.x86_64.rpmが公開されています。 (Microsoft Packages)
インストール済みカーネルを確認する
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel複数のカーネルがインストールされている場合は、複数行が表示されます。
kernel-6.6.143.1-1.azl3.x86_64
kernel-6.6.144.1-1.azl3.x86_64この状態でも、uname -rが次のようになっている場合は対応が完了していません。
6.6.143.1-1.azl3.x86_64修正版のRPMはディスク上にありますが、メモリ上では古いカーネルが動作しています。再起動後にuname -rを再確認してください。
稼働版とインストール版の判断基準
| 確認結果 | 状態 | 必要な対応 |
|---|---|---|
| 稼働版もインストール版も修正版より古い | 未修正 | カーネルを更新して再起動 |
| 修正版がインストール済みだが稼働版が古い | 修正未反映 | 再起動して稼働版を確認 |
稼働版が6.6.144.1-1.azl3 | MSRCのFirstFixedが稼働中 | 動作確認と記録を実施 |
| 稼働版が公式リポジトリのより新しい版 | 通常は修正を含む | ダウングレードせず、導入元と更新履歴を確認 |
kernel-hweやkernel-mshvなど別系統 | 標準kernelの基準だけでは判定不可 | 該当パッケージ向けの修正版情報を確認 |
| 独自ビルドのカーネル | バージョン番号だけでは判定不可 | 修正コミットの取り込み状況をビルド担当者へ確認 |
Intel QATが利用されているか確認する
QATの利用状況は、更新の要否ではなく、対応順を決める材料として確認します。
読み込まれているカーネルモジュールを調べるには、次のコマンドを実行します。
lsmod | grep -E '^(intel_qat|qat_)'カーネルの暗号アルゴリズム一覧にQAT関連の登録があるか確認する場合は、次のコマンドを利用できます。
grep -i qat /proc/cryptoPCIデバイスの情報も確認できます。
lspci -nnk | grep -iA3 -E 'quickassist|qat'ただし、いずれのコマンドでも出力がなかったからといって、CVE-2026-64304の影響を受けないと断定することはできません。ドライバーがカーネルへ組み込まれている場合、デバイスが後から割り当てられる場合、仮想化環境で表示方法が異なる場合などがあるためです。
Azure Linux 3.0のカーネルを修正版へ更新する
Azure Linux 3.0では、パッケージ管理にtdnfが使用されます。Microsoftの資料でも、一般的なパッケージ更新にはtdnf upgradeが対応するコマンドとして案内されています。 (Microsoft Learn)
更新前に確認すること
本番環境では、少なくとも次の準備を行ってください。
- OSディスクのバックアップや復旧手段を確認する
- 再起動可能なメンテナンス時間を確保する
- クラスター構成の場合は1台ずつ更新できるようにする
- QATを利用する暗号処理の確認手順を用意する
- 独自カーネルモジュールやエージェントとの互換性を確認する
/bootとルートファイルシステムの空き容量を確認する
空き容量は次のコマンドで確認できます。
df -h / /boot 2>/dev/null利用可能なカーネルを確認する
sudo tdnf list kernelリポジトリ情報が古い、または期待するパッケージが表示されない場合は、キャッシュとリポジトリを確認します。
sudo tdnf clean all
sudo tdnf repolist
sudo tdnf list availableカーネルだけを更新する
変更範囲をカーネルへ限定する場合は、次のコマンドを使用します。
sudo tdnf upgrade kernel -y組織の更新方針として、利用可能なセキュリティ更新をまとめて適用する場合は、全体を更新します。
sudo tdnf upgrade -y更新後、修正版がインストールされたことを確認します。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel再起動する
カーネル更新は、再起動して新しいカーネルを読み込むまで有効になりません。
sudo systemctl rebootSSH接続が切断された後、ホストが起動したことを確認して再接続します。
再起動後に稼働版を確認する
uname -r標準kernelパッケージの場合、少なくとも次の版が表示されることを確認します。
6.6.144.1-1.azl3.x86_64同じMicrosoft公式パッケージ系統の、より新しい修正版でも問題ありません。6.6.144.1-1は最初の修正版であり、その版へ固定したり、より新しいカーネルからダウングレードしたりするための指定ではありません。
Azure Linuxでは、安定性を維持するためにカーネルなどへ修正をバックポートする方針が取られています。そのため、Linux本家のバージョン番号だけで判断せず、Azure Linuxのパッケージ名、バージョン、リリース番号を一体として確認する必要があります。 (Microsoft Learn)
更新後に実施する確認
カーネル版だけでなく、OSとQATを使用する処理が正常に動いていることも確認します。
システムサービスの確認
systemctl --failed失敗しているサービスが表示された場合は、更新前から存在した問題か、カーネル更新後に発生した問題かを切り分けます。
起動後の重大ログを確認する
sudo journalctl -b -p err..alert --no-pagerQAT、DMA、暗号処理に関連するメッセージを抽出する場合は、次のように確認できます。
sudo dmesg -T | grep -iE 'qat|dma|crypto|error|fail'errorやfailを含む行がすべて今回の更新に関係するとは限りません。更新前のログや正常なフォールバックメッセージと比較して判断してください。
QATを使用する業務処理を確認する
QATを実際に利用している環境では、次の観点でテストします。
- RSA署名処理が成功する
- RSA復号処理が成功する
- TLS終端や暗号化サービスが正常に起動する
- QATデバイスとドライバーが認識されている
- 更新前と比べて処理性能が大きく低下していない
- カーネルクラッシュやDMA関連エラーが発生していない
本番環境へ一斉展開する前に、同一構成の検証機または一部のホストへ先行適用すると、ドライバーや利用アプリケーションとの互換性問題を発見しやすくなります。
AKSのAzure Linux 3.0ノードを利用している場合
Azure Kubernetes Serviceのノードは、長期間利用する単体VMと同じように、各ノードへ手作業でカーネルを更新する運用には向きません。ノードの再作成によって手動変更が失われるため、原則としてAKSのノードイメージ更新を利用します。
現在のノードイメージを確認します。
az aks nodepool show \
--resource-group <リソースグループ名> \
--cluster-name <クラスター名> \
--name <ノードプール名> \
--query nodeImageVersion \
--output tsv利用可能な更新を確認します。
az aks nodepool get-upgrades \
--resource-group <リソースグループ名> \
--cluster-name <クラスター名> \
--nodepool-name <ノードプール名>全ノードプールを最新のノードイメージへ更新する場合は、次のコマンドを使用できます。
az aks upgrade \
--resource-group <リソースグループ名> \
--name <クラスター名> \
--node-image-only \
--yesAKSのLinuxノードイメージは定期的に更新されますが、地域ごとの展開には時間差が生じることがあります。latestNodeImageVersionを確認し、修正を含むイメージが対象リージョンで利用可能になってから更新してください。 (Microsoft Learn)
AKSではセキュリティ更新がノードへインストールされても、カーネル更新を有効にするための再起動が別途必要になる場合があります。ノードイメージ更新、計画メンテナンス、再起動管理のいずれを利用するかを事前に決めておくことが重要です。 (Microsoft Learn)
更新しても6.6.144.1-1が表示されない場合
リポジトリに修正版が見つからない
次の原因を確認します。
- Azure Linux 3.0用リポジトリが無効になっている
- 社内ミラーがMicrosoftのリポジトリと同期していない
- パッケージ除外設定やバージョン固定が行われている
- プロキシやDNS、証明書の問題でリポジトリへ接続できない
- 標準
kernelとは異なるカーネル系統を利用している - イメージ作成時のパッケージスナップショットに固定されている
まず、次の結果を保存して管理者へ共有します。
cat /etc/os-release
uname -r
rpm -q kernel
sudo tdnf repolist
sudo tdnf list kernel修正版を入れたのに古いカーネルが起動する
ブートローダーが古いカーネルを選択している可能性があります。インストール済みカーネル、ブート設定、前回の起動失敗を確認してください。
古いカーネルをすぐに削除するのではなく、新しいカーネルで安定稼働を確認するまで復旧用として残す方法が安全です。
独自モジュールが読み込めない
独自のカーネルモジュールやサードパーティー製ドライバーは、新しいカーネル向けに再ビルドが必要になる場合があります。
次のような機能を使用している環境では、先行検証を推奨します。
- 独自のネットワークドライバー
- ストレージドライバー
- GPUやアクセラレーター向けドライバー
- EDRや監視製品のカーネルモジュール
- DKMS相当の仕組みで構築したモジュール
よくある対応ミス
| ミス | 問題点 | 正しい対応 |
|---|---|---|
rpm -q kernelだけを確認する | 修正版がインストール済みでも古いカーネルが動作している可能性 | uname -rで稼働版も確認 |
| カーネルを更新して再起動しない | 修正コードがメモリへ読み込まれない | メンテナンス時間内に再起動 |
6.6.144だけで比較する | リリース番号やAzure Linux固有のバックポートを見落とす | 6.6.144.1-1.azl3まで確認 |
| FirstFixedへ正確に合わせるためダウングレードする | より新しい修正や機能改善を失う | 公式の最新対応版を利用 |
| QATを使っていないという理由で放置する | 将来の構成変更や利用経路を考慮できない | 優先順位は調整しても更新は実施 |
| AKSノードを1台ずつ手動更新する | ノード再作成で変更が失われる | ノードイメージ更新を使用 |
| CWEを推測で台帳へ登録する | 公開情報と社内記録が食い違う | 「未掲載」と記録し、推定する場合は明記 |
| 更新後の暗号処理を試験しない | QATドライバーや業務処理の不具合を見逃す | RSA処理とサービスを実地確認 |
すぐに更新できない場合の一時的な対策
カーネル更新と再起動をすぐに実施できない場合は、修正までの間に攻撃経路を減らします。
- 信頼できない利用者のシェルアクセスを停止する
- 信頼できないコンテナやジョブを対象ホストで実行しない
- 外部から提供されたRSA秘密鍵を直接読み込ませない
- QATを利用するサービスと鍵の投入経路を限定する
- 不要なQAT機能を停止できるか、依存関係を調査する
- ホスト上での不審なローカル実行や権限変更を監視する
- 再起動を含む更新作業を最優先で計画する
QATドライバーの停止や無効化は、暗号サービスの停止や性能低下を引き起こす可能性があります。影響調査なしにモジュールを強制的に取り外すのではなく、サービス所有者と確認して実施してください。
これらはリスクを下げるための一時措置であり、CVE-2026-64304を修正するものではありません。最終的な対応は、Microsoftが修正済みとしているカーネルへの更新と再起動です。
対応完了の証跡として残す情報
脆弱性管理ツールの検出結果を閉じる前に、次の情報を記録します。
- 対象ホスト名またはリソースID
- Azure Linuxのバージョン
- 更新前の
uname -r - 更新後の
uname -r - インストールしたカーネルRPMの完全な名称
- 再起動日時
systemctl --failedの確認結果- QATまたはRSA関連サービスの動作確認結果
- 作業チケットや変更管理番号
- AKSの場合は更新前後のノードイメージ版
CVE-2026-64304への対応は、修正版RPMを取得した時点ではなく、修正版カーネルが実際に起動し、業務処理が正常であることを確認した時点で完了します。
まとめ：確認すべきなのはインストール版ではなく稼働版
CVE-2026-64304は、Azure Linux 3.0のIntel QATによるRSA CRT処理で、構成要素の長さ検証が不足していたためにカーネルメモリ破損へつながる脆弱性です。CVSSは7.8で、MSRCが示す最初の修正版はazl3 kernel 6.6.144.1-1 on Azure Linux 3.0です。
まずuname -rで実行中のカーネルを確認してください。標準kernelパッケージで修正版より古ければ、tdnfで修正版またはそれ以降へ更新し、再起動します。その後、再びuname -rを実行し、6.6.144.1-1.azl3以上の公式カーネルが動作していることを確認します。
最後に、QATを利用するRSA処理、関連サービス、起動ログを検証し、更新前後のカーネル版を証跡として保存してください。
コメント