CVE-2026-3842対策：Azure Linux 3.0のQEMUを9.1.0-11へ更新

Azure Linux 3.0でQEMU/KVMホストを運用しており、qemu-9.1.0-10.azl3がインストールされている場合は、CVE-2026-3842の影響を受けます。対策はQEMUを9.1.0-11以降へ更新し、稼働中のQEMUプロセスを再生成することです。

パッケージを更新しただけでは、更新前から動いている仮想マシンのQEMUプロセスに修正コードは反映されません。VMの停止・起動、ライブマイグレーション、またはホスト再起動まで含めて対応を計画してください。MSRCは個別の回避策を掲載していないため、設定変更だけで更新を先延ばしにするのは適切ではありません。(msrc.microsoft.com)

CVE-2026-3842の概要

CVE-2026-3842は、QEMUが実装するHyper-V synthetic debugger処理で発生する範囲外書き込みの脆弱性です。

名称に「Hyper-V」とありますが、Windows ServerのHyper-Vそのものではありません。QEMU内にあるHyper-V互換機能の実装が問題となっています。

項目	内容
CVE番号	CVE-2026-3842
対象OS	Azure Linux 3.0
対象パッケージ	azl3 qemu 9.1.0-10
修正版	azl3 qemu 9.1.0-11以降
問題のある処理	Hyper-V synthetic debuggerの受信処理
脆弱性の種類	範囲外書き込み、CWE-787
主な影響	QEMUプロセスのメモリ破損、情報漏えい、データ完全性への影響、サービス拒否
攻撃経路	ゲスト仮想マシン内部からホスト側QEMU処理へ到達
公式回避策	MSRCでは個別の回避策なし
必要な対応	9.1.0-11以降への更新とQEMUプロセスの再起動

2026年7月23日時点で、NVDは独自のCVSS評価をまだ付与していませんが、CNAによるCVSS 3.1スコアとして7.8の「High」が掲載されています。Azure Linux側の修正PRでも、この脆弱性はHighとして扱われています。(nvd.nist.gov)

範囲外書き込みが発生する仕組み

問題は、QEMUの次のソースファイルにあります。

hw/hyperv/syndbg.c

Hyper-V synthetic debuggerの受信処理では、cpu_physical_memory_map()を使ってゲスト物理メモリをホスト側へマッピングします。

しかし、この関数が要求されたサイズより短い領域しかマッピングできなかった場合でも、修正前のコードは当初の要求サイズを前提としてデータを書き込むことがありました。

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

QEMUが書き込みに必要なサイズを計算する
cpu_physical_memory_map()でゲストメモリをマッピングする
実際にマッピングされたサイズが要求サイズより短くなる
短くなったことを十分に検査せず、データを書き込む
マッピング領域やMMIOバウンスバッファの境界を越えて書き込む

修正コードでは、要求したサイズをout_requested_lenとして保存し、実際に取得できたout_lenがそれより小さい場合は書き込みを中止する検査が追加されています。(GitLab)

なぜホスト側の問題として重く見る必要があるのか

この脆弱性で特に注意したいのは、問題が単なるゲストOS内のアプリケーションエラーではなく、仮想マシンを実行しているホスト側のQEMUプロセスで発生する点です。

攻撃者がゲスト仮想マシン内で必要な操作を実行すると、ホスト側QEMUプロセスのメモリ領域を破損させる可能性があります。

想定される影響には次のものがあります。

対象VMを実行しているQEMUプロセスの異常終了
ゲスト仮想マシンの停止
ヒープ上に確保されたオブジェクトの破損
データの完全性への影響
メモリ内情報の漏えい
仮想化ホスト上のサービス拒否

一方で、公開情報だけを根拠に「確実にホストOS上で任意コードを実行できる」「完全なVMエスケープが成立する」と断定するのも適切ではありません。公開されている内容は範囲外書き込みとその潜在的影響を示したものであり、具体的な攻撃チェーンが常に成立することを保証するものではないためです。

ただし、ゲストとホストの信頼境界をまたぐメモリ破損である以上、マルチテナント環境や信頼できないゲストを実行する環境では優先度を上げる必要があります。(nvd.nist.gov)

Azure Linux 3.0がすべて影響を受けるわけではない

Azure Linux 3.0を利用しているだけで、直ちにCVE-2026-3842の攻撃対象になるわけではありません。

主に確認すべきなのは、Azure Linux 3.0が次のような用途で使われているかどうかです。

QEMU/KVMの仮想化ホスト
ネストされた仮想化環境
仮想マシンを実行する検証基盤
VDIやサンドボックス基盤
CI/CDで仮想マシンを起動するホスト
信頼度の異なる複数ゲストを収容する環境

通常のAzure VMとしてAzure Linux 3.0を使用しているだけで、OS内にQEMUホスト機能がインストールされておらず、QEMUプロセスも動いていない場合は、この脆弱性の実行経路はありません。

ただし、脆弱なパッケージがインストールされている場合は、将来QEMUを起動する可能性も考慮し、利用開始前に更新しておくべきです。

影響を受けるバージョンを確認する方法

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

最初にOS情報を確認します。

cat /etc/os-release

出力にAzure Linux 3.0であることを示す情報が含まれているか確認してください。

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

RPMのバージョンとリリース番号まで確認します。

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  | grep -E '^qemu($|-)'

メインのqemuパッケージだけを確認する場合は、次のコマンドも利用できます。

rpm -q qemu

影響を受ける出力例は次のような形式です。

qemu-9.1.0-10.azl3.x86_64

修正済みの出力例は次のとおりです。

qemu-9.1.0-11.azl3.x86_64

9.1.0-11より新しいリリースが提供されている場合は、その新しいパッケージを使用します。

qemuコマンドの表示だけで判断しない

次のコマンドでもQEMUのバージョンを確認できます。

qemu-system-x86_64 --version

ただし、この出力は主に上流バージョンの9.1.0を表示するため、Azure LinuxのRPMリリース番号である-10と-11を区別できない場合があります。

上流QEMUでは9.1.0が影響範囲に含まれますが、Azure Linuxは修正コードを9.1.0へバックポートし、RPMリリースを9.1.0-11へ更新しています。そのため、判定にはRPMのRelease番号まで必要です。(nvd.nist.gov)

QEMUプロセスが動いているか確認する

次のコマンドで、現在稼働しているQEMUプロセスを確認します。

pgrep -af 'qemu-system|qemu-kvm'

プロセスが表示される場合は、そのホストで仮想マシンが実際に動作している可能性があります。

パッケージがインストールされていてもプロセスが動いていない場合、現在の攻撃経路は限定されます。ただし、QEMUを次回起動する前に更新してください。

対応の優先順位

環境	対応優先度	判断理由
信頼できないゲストを収容するマルチテナント環境	最優先	ゲストからホスト側QEMUへ到達する脆弱性のため
VDI、検証環境、サンドボックス、CI基盤	高	利用者がゲスト内部でコードを実行できる可能性が高い
インターネット公開サービスを実行するゲストのホスト	高	ゲスト侵害後の二段階目の攻撃に利用される可能性がある
管理者だけが利用する単一テナント環境	中～高	攻撃条件は限定されるが、ホスト境界の問題である
QEMUパッケージはあるがVMを起動していない	中	次回起動前に更新すれば実行経路を閉じられる
QEMU未導入、または9.1.0-11以降	原則対象外	対象パッケージがない、または修正済み

「外部からQEMUのポートが見えないから安全」とは限りません。想定される起点はゲスト仮想マシン内部であるため、ゲストOSが侵害された後の追加攻撃として利用される可能性も考慮する必要があります。

QEMUを9.1.0-11以降へ更新する手順

更新前に稼働中のVMを確認する

libvirtを利用している場合は、次のコマンドで仮想マシンを確認できます。

sudo virsh list --all

更新前に、少なくとも次の項目を整理してください。

稼働中のVM一覧
各VMの停止可否
ライブマイグレーションの可否
ストレージとネットワークの冗長性
バックアップや復旧手順
更新後の動作確認担当者
問題発生時のロールバック方法

Azure Linuxのパッケージを更新する

リポジトリ情報を更新したうえで、パッケージ更新を実行します。

sudo tdnf clean all
sudo tdnf update -y

全パッケージの更新が難しい環境では、変更管理の方針に従ってQEMU関連パッケージだけを更新します。ただし、QEMUは複数のサブパッケージに分かれる場合があるため、メインパッケージだけでなく、実際にQEMUホストバイナリを提供しているパッケージ群の整合性を確認してください。

更新後のRPMバージョンを確認する

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  | grep -E '^qemu($|-)'

少なくとも、対象となるホスト側QEMUパッケージが次の状態になっていることを確認します。

9.1.0-11.azl3

または、それより新しいリリースであれば修正済みとして扱えます。

Azure Linuxの修正では、RPMのReleaseが10から11へ更新され、CVE-2026-3842のパッチが追加されています。(GitHub)

更新後はQEMUプロセスの再起動が必要

RPMを更新しても、更新前から稼働しているQEMUプロセスは、旧コードをメモリ上で使い続けます。

対応方法は運用構成に応じて、次のいずれかを選択します。

仮想マシンを停止して再度起動する
仮想マシンを別ホストへライブマイグレーションする
更新済みホスト上でQEMUプロセスを再生成する
メンテナンス時間を確保してホストを再起動する

単にlibvirtdなどの管理サービスだけを再起動しても、既存の仮想マシンプロセスがそのまま残る構成があります。重要なのは、更新前から動いているQEMUプロセス自体を終了し、修正版バイナリで新しく起動することです。

古いQEMUプロセスが残っていないか確認する

for pid in $(pgrep -f 'qemu-system|qemu-kvm'); do
  printf 'PID=%s EXE=' "$pid"
  readlink "/proc/$pid/exe"
done

出力の末尾に(deleted)と表示される場合は、更新によって削除された旧バイナリを、そのプロセスが引き続き使用している可能性があります。

/usr/bin/qemu-system-x86_64 (deleted)

この状態のQEMUプロセスは再起動してください。

ただし、(deleted)が表示されない場合でも、更新前から継続稼働しているVMについては、プロセスの起動時刻を確認したうえで再生成するのが安全です。

ps -eo pid,lstart,args \
  | grep -E '[q]emu-system|[q]emu-kvm'

更新後に確認すべき項目

QEMUプロセスを再起動した後は、パッケージ番号だけでなく、仮想化基盤としての機能も確認します。

確認項目	確認内容
QEMUパッケージ	9.1.0-11以降になっている
稼働プロセス	更新後に新しく起動されている
VM起動	対象VMが正常に起動する
ネットワーク	IPアドレス、疎通、DNS、外部接続が正常
ストレージ	仮想ディスクの読み書きが正常
ゲストエージェント	管理機能やシャットダウン連携が正常
ライブマイグレーション	利用環境では移行が正常に完了する
バックアップ	スナップショットやバックアップ処理が正常
監視	QEMU、libvirt、VM関連の新規エラーがない

ログも併せて確認します。

sudo journalctl -b -p warning

libvirtを使用している場合は、環境に応じて次のようなログも確認してください。

sudo journalctl -u libvirtd

公式の回避策がない場合の考え方

MSRCはCVE-2026-3842について、個別の回避策を掲載していません。したがって、正式な対応は修正版への更新です。(msrc.microsoft.com)

Hyper-V synthetic debugger関連機能を無効化すれば攻撃経路を狭められる可能性はありますが、次の理由からパッチの代替として扱うべきではありません。

実際に脆弱な処理へ到達できなくなったか検証が必要
QEMUの起動オプションや管理基盤によって設定方法が異なる
VMの互換性やデバッグ機能へ影響する可能性がある
将来の設定変更で再び有効になる可能性がある
MSRCが公式回避策として保証していない

緊急時に一時的なリスク低減策を取る場合でも、最終的には9.1.0-11以降への更新を完了させる必要があります。

対応で間違えやすいポイント

間違った対応	問題点	正しい対応
`qemu-guest-agent`だけ更新する	脆弱性はホスト側QEMUの`syndbg.c`にある	QEMU/KVMホスト側のパッケージを更新する
`qemu --version`だけ確認する	9.1.0-10と9.1.0-11を区別できない	RPMのRelease番号まで確認する
RPM更新後もVMを動かし続ける	稼働中プロセスが旧コードを保持する	VMまたはQEMUプロセスを再起動する
ファイアウォールだけ設定する	攻撃の起点はゲスト内部となり得る	ゲストの信頼性にかかわらずパッチを適用する
ホストを再起動するだけ	脆弱なRPMが残っていれば修正されない	パッケージ更新後に再起動する
CVSSだけで後回しにする	仮想化の信頼境界に関係する	テナント構成やゲストの信頼度も含めて判断する
すべてのAzure Linux VMが対象だと考える	QEMUホストでない環境まで混同する	QEMUパッケージと稼働プロセスを確認する

CVE-2026-3842対応の最終チェックリスト

[ ] Azure Linux 3.0をQEMU/KVMホストとして使用しているか確認した
[ ] rpmコマンドでQEMUのRelease番号まで確認した
[ ] qemu-9.1.0-10.azl3が残っていないことを確認した
[ ] QEMUを9.1.0-11以降へ更新した
[ ] 更新前から稼働していたVMまたはQEMUプロセスを再起動した
[ ] /proc/<PID>/exeに旧バイナリが残っていないことを確認した
[ ] VMの起動、ネットワーク、ストレージを確認した
[ ] 監視ログに新しいエラーがないことを確認した
[ ] 更新日時、対象ホスト、更新後バージョンを記録した

CVE-2026-3842では、QEMUの上流バージョンが同じ9.1.0でも、Azure LinuxのRPMリリース番号によって修正状況が異なります。まずrpmで9.1.0-10の有無を確認し、該当する場合は9.1.0-11以降へ更新してください。その後、更新前から稼働しているQEMUプロセスを確実に再生成するところまでが対策です。

この記事を書いた人

佐藤健司

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

CVE-2026-3842対策：Azure Linux 3.0のQEMUを9.1.0-11へ更新

CVE-2026-3842の概要

範囲外書き込みが発生する仕組み

なぜホスト側の問題として重く見る必要があるのか

Azure Linux 3.0がすべて影響を受けるわけではない

影響を受けるバージョンを確認する方法

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

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

qemuコマンドの表示だけで判断しない

QEMUプロセスが動いているか確認する

対応の優先順位

QEMUを9.1.0-11以降へ更新する手順

更新前に稼働中のVMを確認する

Azure Linuxのパッケージを更新する

更新後のRPMバージョンを確認する

更新後はQEMUプロセスの再起動が必要

古いQEMUプロセスが残っていないか確認する

更新後に確認すべき項目

公式の回避策がない場合の考え方

対応で間違えやすいポイント

CVE-2026-3842対応の最終チェックリスト

この記事を書いた人

コメント

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

CVE-2026-3842対策：Azure Linux 3.0のQEMUを9.1.0-11へ更新

CVE-2026-3842の概要

範囲外書き込みが発生する仕組み

なぜホスト側の問題として重く見る必要があるのか

Azure Linux 3.0がすべて影響を受けるわけではない

影響を受けるバージョンを確認する方法

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

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

qemuコマンドの表示だけで判断しない

QEMUプロセスが動いているか確認する

対応の優先順位

QEMUを9.1.0-11以降へ更新する手順

更新前に稼働中のVMを確認する

Azure Linuxのパッケージを更新する

更新後のRPMバージョンを確認する

更新後はQEMUプロセスの再起動が必要

古いQEMUプロセスが残っていないか確認する

更新後に確認すべき項目

公式の回避策がない場合の考え方

対応で間違えやすいポイント

CVE-2026-3842対応の最終チェックリスト

この記事を書いた人

関連記事

コメント

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

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