Xen ハイパーバイザーのゲストエスケープ(CVE-2026-102703、CVE-2026-102704)
Grant copy の 2 つの検証不備により、悪意ある Xen ゲストは Dom0 を含む他ドメインのメモリを読み書きできます。XSA-523 パッチを今すぐ適用してください。
TL;DR
- Xen の grant copy 操作における 2 つの検証不備により、悪意あるゲストは Dom0(制御ドメイン)を含む他ドメインのメモリを読み書きできます。Xen Project は 2026 年 11 月 3 日にアドバイザリ XSA-523 を公表しました。
- Xen は 4.6 以降の全バージョンが対象で、4.5 以前は対象外です。既知の緩和策はありません。
- アドバイザリは CVSS スコアを示していません。悪用は報告されておらず、2026 年 11 月 4 日時点でどちらの CVE も米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)の Known Exploited Vulnerabilities(KEV)カタログに載っていません。
- 4.17 から unstable までの XSA-523 パッチを安定ブランチの最新リビジョンに適用するか、プラットフォームベンダーの更新を適用してください。修正を含むリリース済み Xen の tarball はまだありません。「修正するには?」を参照。
影響を受けますか?
次の条件がすべて成り立つとき露出します:
- Xen ハイパーバイザーをバージョン 4.6 以降で実行している。アドバイザリは 4.6 以降の全バージョンが脆弱で、4.5 以前は脆弱でないと述べています。
- 信頼できないゲストを実行している。grant table を操作できるゲストは誰でも、脆弱なコピー操作を発行できます。
- まだ XSA-523 パッチを適用していない。アドバイザリの解決策はパッチ一式で、2026 年 11 月 4 日時点でそれを含むリリース済み Xen の tarball はありません。
ここではゲスト自身が攻撃者であり、ネットワーク攻撃者の犠牲者ではありません。悪意ある隣接ゲストにメモリを読み書きされたゲスト側には、その徴候が一切現れません。
| ブランチ | 対象バージョン | 修正 |
|---|---|---|
| xen-unstable、4.22.x から 4.19.x | 全リリース | xsa523-1.patch、xsa523-2.patch |
| 4.18.x から 4.17.x | 全リリース | xsa523-4.18-1.patch、xsa523-4.18-2.patch |
| 4.6.x から 4.16.x | 全リリース | Xen Project からのパッチなし。これらのブランチはサポート終了 |
XCP-ng は Xen Project のプラットフォームで、そのドキュメントは Xen ハイパーバイザーを中心に構築されていると述べています。ホストの実態を確認:
# On the host (dom0): the running Xen version
xl info | grep '^xen_version'
# In a Linux guest: confirms the hypervisor type (prints "Xen" under Xen)
cat /sys/hypervisor/type 2>/dev/null
# In a Linux guest: the hypervisor version the guest was told
cat /sys/hypervisor/version/major 2>/dev/null
cat /sys/hypervisor/version/minor 2>/dev/null
バージョンはホストが影響範囲にあるかを示し、4.6 以降のリリースはすべて該当します。どのリリースにもパッチが含まれていないため、XSA-523 パッチが適用済みかどうかはバージョンでは分かりません。代わりにベンダーのアドバイザリかパッケージの変更履歴で XSA-523 を確認してください。
マネージドクラウドでは、ゲストから見た状態がホストのパッチ適用状況より遅れていることがあります。その上で信頼できないゲストを実行している場合は、プロバイダーにホストの XSA-523 対応状況を確認してください。
修正するには?
- 安定ブランチから Xen をビルドしている場合は、まずブランチを最新リビジョンまで更新してから XSA-523 パッチを適用します。Xen を再ビルドし、パッチ適用済みのハイパーバイザーでホストを再起動します。アドバイザリは、パッチが安定ブランチ向けに用意されており、リリース tarball にはそのまま適用できない場合があると注意しています。
- プラットフォームベンダーやディストリビューションがパッケージした Xen を実行している場合は、ベンダーの更新が公開されたら適用し、ホストを再起動します。2026 年 11 月 4 日時点で、修正を含むリリース済み Xen の tarball はありませんでした。
- ゲストの再作成は復旧計画が必要とする範囲で行ってください。ハイパーバイザーのパッチ適用は将来の攻撃を止めますが、以前に攻撃が起きたかどうかは示しません。
設定による回避策はありません。アドバイザリはこう述べています:「There is no known mitigation(既知の緩和策はない)」。
根本原因は何か?
grant copy のハイパーコールは、ゲストが grant reference とマシンフレーム番号の間でデータをコピーできるようにするものです。性能のため、コミット d28f42f2703e(「grant-table: defer releasing pages acquired in a grant copy」)により、Xen は直前のバッチ要素の検証済み記述をキャッシュするようになりました。このコミットが最初に含まれたのは Xen 4.6.0 で、アドバイザリの脆弱バージョン範囲と一致します。
grant copy 操作のバッチは、同じ送信元または送信先ページ内の隣接アドレス範囲に対して作用することがよくあります。キャッシュは次の要素が等価に見えるときに再利用されます。アドバイザリの説明では、2 つの脆弱性はどちらもこの再利用の条件の誤りです。
CVE-2026-102703 はキャッシュ妥当性チェックです。gnttab_copy_buf_valid() では、p は新しい要素の送信元または送信先、b はキャッシュされたバッファです。has_gref は新しい要素が grant reference(GREF)を使うかどうかを示します。脆弱なコードは、パッチ適用前の xen-unstable の xen/common/grant_table.c 3082 行目から 3091 行目です:
static bool gnttab_copy_buf_valid(
const struct gnttab_copy_ptr *p, const struct gnttab_copy_buf *b,
bool has_gref)
{
if ( !b->virt )
return 0;
if ( has_gref )
return b->have_grant && p->u.ref == b->ptr.u.ref;
return p->u.gmfn == b->ptr.u.gmfn;
}
->have_grant フィールドは、キャッシュされたエントリが grant reference 由来かどうかを記録します。コードがこれを確認するのは grant reference の経路だけで、GREF の比較の前のみです。マシンフレームの経路は p->u.gmfn == b->ptr.u.gmfn を比較しますが、キャッシュされたエントリもフレームのエントリであるかは確認しません。
パッチの説明は、その結果を次のように述べています:より前のバッチ要素の(おそらく無効な)GREF が、(有効かもしれない)マシンフレーム番号(MFN)と混同されることがあります。
CVE-2026-102704 は権限チェックです。フレーム番号によるコピー(grant reference ではなく)は、呼び出し元自身のメモリを対象とするときのみ許可されます。パッチ適用前は、同じファイルの 2939 行目から 2946 行目で gnttab_copy_lock_domain() がこれを強制します:
static int gnttab_copy_lock_domain(domid_t domid, bool is_gref,
struct gnttab_copy_buf *buf)
{
/* Only DOMID_SELF may reference via frame. */
if ( domid != DOMID_SELF && !is_gref )
return GNTST_permission_denied;
buf->domain = rcu_lock_domain_by_any_id(domid);
gnttab_copy_one() がこのチェックに到達するのは、3140 行目から 3150 行目でドメインをロックし直すときだけです。ここで op はバッチの現在の要素、src と dest はキャッシュされた送信元と送信先のバッファです:
if ( !src->domain || op->source.domid != src->ptr.domid ||
!dest->domain || op->dest.domid != dest->ptr.domid )
{
gnttab_copy_release_buf(src);
gnttab_copy_release_buf(dest);
gnttab_copy_unlock_domains(src, dest);
rc = gnttab_copy_lock_domains(op, src, dest);
if ( rc < 0 )
goto out;
}
直前の要素と同じドメインを名指しする要素は、このブロックを飛ばします。その要素のフレーム番号によるコピーは、DOMID_SELF と照合されません。
どのように悪用されるか?
CVE-2026-102703 について:
- 悪意あるゲストが
GNTTABOP_copyバッチを発行します。先頭の要素が grant reference でコピーするため、キャッシュは検証済みの grant エントリを保持します。 - 同じバッチの後続の要素がマシンフレーム番号でコピーするため、Xen はそのフレーム番号をキャッシュされたエントリと比較します。
- この比較は、キャッシュされたエントリがフレームのエントリだったかを確認しません。先の grant reference がフレーム番号と混同され、Xen はキャッシュされたバッファを再利用します。
- コピーはゲストが正当にはアドレス指定できないメモリを読み書きします。それは Dom0 を含む他ドメインに属します。
CVE-2026-102704 について:
- 悪意あるゲストがコピーバッチを発行します。最初の要素が grant reference で外部ドメインを名指しし、チェックを通過して、Xen はそのドメインをロックします。
- 後続の要素は同じドメインを名指ししますが、フレーム番号でコピーします。
gnttab_copy_one()はドメインロック処理を飛ばすため、「フレームで参照できるのは DOMID_SELF のみ」というチェックは実行されません。 - ゲストは grant なしで、マシンフレーム番号により直接他ドメインのメモリをアドレス指定します。
どちらの経路も特殊なゲスト設定を必要とせず、機能している grant table のみが必要です。公開されている PoC はなく、パッチ自体が到達可能な動作を文書化しています。
攻撃はどのように流れるか?
grant copy 操作のバッチがキャッシュ済みの状態を再利用し、要素ごとの 2 つのチェックのどちらかが欠けていることで、ゲストは他ドメインのメモリをアドレス指定できるようになります。
GNTTABOP_copy バッチを発行"] --> B["先行要素は grant reference で
検証済み"] B --> C["後続要素が
フレーム番号でコピー"] C --> D["CVE-2026-102703:アドレス指定モードのチェックなし、
GREF をフレーム番号と混同"] C --> E["CVE-2026-102704:ドメインを再ロックせず、
DOMID_SELF チェックなし"] D --> F["Dom0 を含む他ドメインの
メモリを読み書き"] E --> F
攻撃者に何ができるか?
悪意あるゲストは、アドバイザリの言葉を借りれば、Dom0 を含む他ドメインに属する任意のメモリを読み書きできます。これが情報源が許す最も強い主張です。
実際には、このアクセスによって別ゲストのメモリ内の秘密が漏れたり、別ゲストのコードやデータが改変されたりする可能性があります。そのような攻撃を実証した公開情報はありません。アドバイザリは CVSS スコアを示しておらず、実世界での悪用も報告されていません。
攻撃者には、未修正のホスト上のゲストの制御権が必要です。信頼できるゲストのみを実行するホストは、それらのゲストのいずれかが先に侵害された場合にのみ露出します。
なぜ修正は機能するか?
CVE-2026-102703 のパッチは、新しい要素のアドレス指定モードがキャッシュと異なるとき、キャッシュの再利用を拒否します:
static bool gnttab_copy_buf_valid(
const struct gnttab_copy_ptr *p, const struct gnttab_copy_buf *b,
bool has_gref)
{
- if ( !b->virt )
+ if ( !b->virt || b->have_grant != has_gref )
return 0;
if ( has_gref )
- return b->have_grant && p->u.ref == b->ptr.u.ref;
+ return p->u.ref == b->ptr.u.ref;
return p->u.gmfn == b->ptr.u.gmfn;
}
grant reference は、マシンフレーム番号と比較されたり混同されたりできなくなります。このチェックは報告された脆弱性に対して完全です。キャッシュが参照されるのは、アドレス指定モードが一致するときだけだからです。
CVE-2026-102704 のパッチは DOMID_SELF チェックを gnttab_copy_lock_domain() から削除し、gnttab_copy_claim_buf() に追加します:
buf->ptr.u.ref = ptr->u.ref;
buf->have_grant = 1;
}
+ /* Only DOMID_SELF may reference via frame. */
+ else if ( ptr->domid != DOMID_SELF )
+ return GNTST_permission_denied;
else
{
rc = get_paged_frame(ptr->u.gmfn, &buf->mfn, &buf->page,
gnttab_copy_claim_buf() は、要素がキャッシュされたバッファを再利用できないときに必ず実行されます。そのため、権限チェックはドメインロック処理が実行されたかどうかに依存しなくなります。
2 つのパッチを当てると、バッチの各要素は再利用の前に 2 つの防御を通ります:
アドレス指定モード?"} B -- "いいえ" --> C["キャッシュ拒否、
完全な検証を実行"] B -- "はい" --> D{"外部ドメインを名指しして
フレームでコピー?"} D -- "はい" --> E["その要素に
GNTST_permission_denied"] D -- "いいえ" --> F["検証済みバッファ上で
コピー続行"]
侵害されたか確認するには?
公表されたインジケーターはありません。アドバイザリは検出シグネチャを記述しておらず、ドメイン間のメモリ読み書きは犠牲ゲストから見える痕跡を残しません。
ホスト上では、攻撃はごく普通の grant copy ハイパーコールを発行するゲストであり、ログ上は通常の grant table の活動に見えます。パッチ適用前に信頼できないゲストを実行していたホストは、テナントの秘密が露出した可能性があるものとして扱い、Xen ベンダーに検出支援を問い合わせるべきです。
年表
- 2015-01-29:コミット
d28f42f2703eが grant copy のキャッシュを Xen のツリーに追加。 - 2015-10-07:Xen Project が、このコミットを含む最初のリリースである Xen 4.6.0 にタグを付与。
- 2026-11-03:Xen Project が XSA-523 バージョン 2 を 12:00 UTC に公開し、Xen 4.17 から unstable までのパッチと 2 つの CVE 識別子を添付。
FAQ
KVM、Hyper-V、VMware のホストには影響しますか?
いいえ。脆弱性は Xen の grant table コードにあり、このハイパーバイザー固有のものです。他のハイパーバイザーのホストは影響を受けません。
CVE レコードは公開されていますか?
いいえ。2026 年 11 月 4 日時点で、CVE データベースには CVE-2026-102703 と CVE-2026-102704 のレコードがありません。アドバイザリが両識別子を挙げているため、レコードが公開されるまでアドバイザリを参照してください。
誰がこの脆弱性を見つけたのですか?
アドバイザリのクレジットによれば、Anthropic が Claude を使って発見し、Ada Logics の Stephan Lipp が検証しました。CodeAnt AI Security Research チームが独立に報告しました。修正パッチには「Assisted-by: Claude」の行があります。アドバイザリは最初の報告日を示していません。
サポート終了ブランチ(4.16 以前)を実行しています。どうすればよいですか?
Xen Project はそれらのブランチ向けにパッチを提供しません。保守中のブランチ(4.17 以降)に移行し、そこへ XSA-523 パッチを適用してください。
クラウドプロバイダーが Xen を実行しています。対応は必要ですか?
ゲストからプロバイダーのホストにパッチを当てることはできません。プロバイダーに XSA-523 の対応状況を確認し、修正を確認できるまでテナント間の秘密はプロバイダーの責任と考えてください。
テナントに悪用される前に、保有する Xen ホストを見つけて修正する
信頼できないゲストのために Xen を実行するホストがここでの露出であり、攻撃者はインターネット上のスキャナーではなく同じホスト上のテナントです。Ostorlab の攻撃面の発見はインターネットに公開しているサーバーと管理インターフェースを棚卸しし、XSA-523 の対応状況を確認すべき Xen ホストの最初の一覧になります。内部ネットワークからしか到達できないホストは、独自の棚卸しが必要です。
参考文献
- Xen Security Advisory 523 バージョン 2、「arbitrary read/write via grant copy」、2026-11-03 公開:https://xenbits.xenproject.org/xsa/advisory-523.html(2026 年 11 月 4 日確認)
- XSA-523 パッチ 1、「gnttab: complete checking in gnttab_copy_buf_valid()」、CVE-2026-102703:https://xenbits.xenproject.org/xsa/xsa523-1.patch(2026 年 11 月 4 日確認)
- XSA-523 パッチ 2、「gnttab: move 'only local domain may copy by frame' check」、CVE-2026-102704:https://xenbits.xenproject.org/xsa/xsa523-2.patch(2026 年 11 月 4 日確認)
- OSS Security メーリングリスト上の XSA-523 バージョン 2 のコピー:https://www.openwall.com/lists/oss-security/2026/11/03/6(2026 年 11 月 4 日確認)
- Xen ソースコード、XSA-523 パッチ適用前の
xen/common/grant_table.c(コミット c89185286cbe):https://github.com/xen-project/xen/blob/c89185286cbe74f584e2ddca9bfa6654a8600502/xen/common/grant_table.c(2026 年 11 月 4 日確認) - Xen コミット d28f42f2703e、「grant-table: defer releasing pages acquired in a grant copy」、2015-01-29:https://github.com/xen-project/xen/commit/d28f42f2703e483116bafd2b0b76a32af67d83ad(2026 年 11 月 4 日確認)
- Xen 4.6.0 リリースタグ、RELEASE-4.6.0、2015-10-07:https://github.com/xen-project/xen/releases/tag/RELEASE-4.6.0(2026 年 11 月 4 日確認)
- Xen Project、XCP-ng プロジェクトページ:https://xenproject.org/projects/xcp-ng/(2026 年 11 月 4 日確認)
- XCP-ng ドキュメント、「XCP-ng contains multiple components, built around the Xen Hypervisor」:https://docs.xcp-ng.org/(2026 年 11 月 4 日確認)
- CISA の Known Exploited Vulnerabilities カタログ、JSON フィード、両 CVE 識別子で検索:https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json(2026 年 11 月 4 日確認)