【CVE-2026-46316】KVM arm64 vgic-its 脆弱性 — 「同じセキュリティ更新でも自社環境には無関係」と断言できる理由

« ハブ記事「Linuxカーネル432件CVE公開ニュースから16件を洗い出した話」へ戻る

【CVE-2026-46316】KVM/arm64「ITScape」を解説―x86_64環境が影響対象外でもカーネル更新は必要な理由

冒頭文

CVE-2026-46316は、LinuxカーネルのKVM/arm64に実装されている仮想割り込みコントローラー「vGIC-ITS」に存在する、参照カウント管理の脆弱性です。

攻撃が成功すると、ARM64の仮想マシン内にいる攻撃者が仮想マシンの境界を越え、KVMホストのカーネル権限でコードを実行する可能性があります。

発見者は本脆弱性を「ITScape」と命名し、ゲストからホストへ脱出するPoCを公開しています。

ただし、すべてのLinuxサーバーが影響を受けるわけではありません。

CVE-2026-46316が成立するのは、主に次の環境です。

• CPUアーキテクチャがARM64である

• LinuxサーバーがKVMホストとして動作している

• ARM64ゲストにvGICv3とITSを提供している

• 攻撃者がゲストOS内でカーネル権限を持っている

• ホストカーネルに修正が適用されていない

kurutann.comの本番VPSはx86_64で動作しています。

脆弱な処理はarch/arm64/kvm/vgic/vgic-its.cに存在するARM64専用コードです。そのため、kurutann.comのゲストOSカーネルは、CVE-2026-46316の直接的な影響対象ではありません。

ただし、ここで重要な注意点があります。

CVE-2026-46316がx86_64に無関係であっても、ELSA-2026-500004というカーネル更新全体を省略してよいわけではありません。

この記事では、脆弱性の仕組み、自分の環境への影響判定、ELSAの読み方、確認コマンド、アップデート方法、再発防止まで詳しく解説します。

結論・要点

最初に結論をまとめます。

NVDにはNVD独自のCVSSスコアはまだ付けられていません。

CVEを管理するkernel.orgはCVSS 3.1で9.3、Red Hatは7.0と評価しています。評価差は、ゲストOSの権限をどのように扱うか、攻撃条件の複雑さ、ゲストとホストの境界をCVSSのスコープ変更として扱うかなど、評価前提の違いによるものです。

この記事で分かること

この記事では、次の内容を解説します。

• CVE-2026-46316で何が起きるのか

• KVM、ARM64、vGIC、ITSとは何か

• 参照カウントの二重解放が発生する仕組み

• なぜゲストからホストへ脱出できるのか

• x86_64が対象外になる技術的な理由

• OracleのELSAにx86_64パッケージが含まれる理由

• 自分のサーバーを確認するコマンド

• 修正カーネルへの更新方法

• 更新後の動作確認

• ARM64 KVMホストを運用する場合の再発防止

対象読者・前提環境

対象読者は次のとおりです。

• Linuxサーバーを管理している人

• KVMやQEMUで仮想マシンを運用している人

• ARM64サーバーを使用している人

• Oracle LinuxのUEKを使用している人

• 脆弱性スキャナーでCVE-2026-46316を検出された人

• セキュリティ更新に含まれるCVEの影響を正確に判定したい人

• CVE件数の多さによるアラート疲れを防ぎたい人

コマンドは、原則として調査対象のLinuxサーバー上で実行します。

用語と全体像

KVMとは

KVMはKernel-based Virtual Machineの略です。

簡単にたとえると、Linuxカーネルを「仮想マシンを動かす土台」に変える機能です。

KVMを使用すると、一台の物理サーバー上で複数のLinuxやWindowsを仮想マシンとして実行できます。

KVMの利用では、一般に次のような構成になります。

物理サーバー
  │
  ├─ Linuxホストカーネル
  │    └─ KVM
  │
  ├─ 仮想マシンA
  ├─ 仮想マシンB
  └─ 仮想マシンC

KVMは/dev/kvmを通じて、ユーザー空間の仮想マシン管理プログラムから操作されます。Linuxカーネルの公式ドキュメントでも、/dev/kvmを開いて仮想マシンや仮想CPUを作成するAPIとして説明されています。

ARM64とは

ARM64は、64ビットARMアーキテクチャです。

Linuxでは、次のように表示されることが一般的です。

aarch64

一方、IntelやAMDの一般的な64ビットサーバーは、次のように表示されます。

x86_64

ARM64とx86_64は、同じ64ビットCPUでも命令セットやカーネル内部の実装が異なります。

Linuxカーネルでは、アーキテクチャ固有のコードが別々のディレクトリに格納されています。

arch/
├─ arm64/
├─ x86/
├─ riscv/
├─ powerpc/
└─ s390/

CVE-2026-46316の脆弱なコードは、次のARM64専用パスにあります。

arch/arm64/kvm/vgic/vgic-its.c

vGICとは

GICはGeneric Interrupt Controllerの略です。

簡単にたとえると、CPUに対して「ネットワーク通信が届いた」「ディスク処理が終わった」などの通知を配る交通整理係です。

vGICは、仮想マシン向けにKVMが再現する仮想的なGICです。

KVMの公式ドキュメントでは、ARM仮想マシンにGICv3を作成し、仮想CPUや仮想デバイスからの割り込みを処理する仕組みが定義されています。

ITSとは

ITSはInterrupt Translation Serviceの略です。

簡単にたとえると、デバイスから届いた割り込み通知を、対応する仮想CPUと仮想割り込み番号へ変換する案内所です。

PCI Expressデバイスが使用するMSIやMSI-Xなどのメッセージ型割り込みを、GICの割り込みへ変換します。

参照カウントとは

参照カウントは、メモリー上のデータを何か所から使用しているか数える仕組みです。

図書館の貸出カードにたとえると、まだ誰かが本を借りている間は、本を廃棄してはいけません。

参照カウント 2
  ├─ 利用者Aが使用中
  └─ 利用者Bが使用中

一人が使用を終えると、参照カウントを一つ減らします。

2 → 1

参照カウントがゼロになった時点で、メモリーを解放できます。

1 → 0 → メモリー解放

問題は、同じ参照を二回減らしてしまう場合です。

本来：1 → 0
誤り：1 → 0 → -1相当

まだ別の処理が使用しているデータを解放すると、Use-After-Freeにつながります。

CVE-2026-46316で何が起きたのか

問題の関数は、次の関数です。

vgic_its_invalidate_cache()

この関数は、ITSごとに保持されている変換キャッシュを無効化します。

変換キャッシュには、デバイスとイベントから仮想割り込みへの変換結果が保存されています。

本来は、キャッシュから実際に削除できたエントリに対してだけ、参照カウントを一つ減らす必要があります。

しかし、修正前のコードは、xa_erase()が返した「実際に削除したエントリ」ではなく、走査中に確認したポインターへvgic_put_irq()を実行していました。

なぜ二重解放が発生したのか

vgic_its_invalidate_cache()は、複数の異なる処理経路から呼び出されます。

主な経路は次のとおりです。

• ITSコマンドの処理

• GITS_CTLRへの書き込み

• リディストリビューターのGICR_CTLRでEnableLPIsを無効化する処理

これらの経路は、同じロックだけで相互排他されていません。

そのため、複数のCPUまたは仮想CPU関連処理が、同じキャッシュエントリを同時に確認する可能性があります。

処理A：エントリXを確認
処理B：エントリXを確認

処理A：エントリXを削除
処理B：削除を試みるが、既に存在しない

処理A：エントリXの参照を減らす
処理B：走査時のポインターを使って参照をもう一度減らす

キャッシュが持つ参照は一つしかありません。

同じ参照が二回減らされると、まだITEがエントリを参照しているにもかかわらず、メモリーが解放される可能性があります。

修正前後の考え方

次は実際のカーネルコードを簡略化した概念図です。

修正前の問題

/* 概念コード */
xa_for_each(cache, index, iterated_entry) {
    xa_erase(cache, index);

    /*
     * 他の処理が先に削除していた場合でも、
     * 走査時に見えたポインターを解放してしまう
     */
    vgic_put_irq(iterated_entry);
}

二つの処理が同じエントリを見た場合、両方がvgic_put_irq()を実行する可能性があります。

修正後の考え方

/* 概念コード */
xa_for_each(cache, index, iterated_entry) {
    erased_entry = xa_erase(cache, index);

    /*
     * この処理が実際に削除できた場合だけ
     * 参照を減らす
     */
    if (erased_entry)
        vgic_put_irq(erased_entry);
}

xa_erase()はアトミックにエントリを削除し、削除前の値を返します。

先に別の処理が削除していた場合、後から実行した処理は削除対象を取得できません。

そのため、実際に削除できた処理だけが参照を減らせば、二重解放を防止できます。

攻撃が成立する流れ

┌────────────────────────┐
│ ARM64のKVMホスト        │
│ 修正前のLinuxカーネル   │
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│ 攻撃者が管理するゲストVM│
│ ゲスト内ではroot権限    │
└───────────┬────────────┘
            │
            │ GIC/ITSのMMIO操作
            ▼
┌────────────────────────┐
│ 複数経路からITSキャッシュ│
│ 無効化を同時に発生       │
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│ 同じ参照を複数回解放     │
│ double-put              │
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│ Use-After-Free          │
│ ホストカーネルメモリー破壊│
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│ ゲストからホストへ脱出   │
│ ホストカーネル権限を取得 │
└────────────────────────┘

発見者が公開したPoCでは、ゲストからKVMのvGIC-ITS処理を操作し、ホスト側にroot所有の/ITScapeファイルを作成することで、ホストカーネル上でのコード実行を実証しています。

PoCは公開されているのか

CVE-2026-46316には、発見者によるPoCが公開されています。

ただし、このPoCについては区別が必要です。

公開PoCは、KVMセルフテストを基にした実証コードです。

特定のクラウド環境を即座に攻撃できるように完全武器化されたコードではありません。実環境で使用するには、対象カーネルのアドレス、オフセット、競合タイミング、ガジェットなどに合わせた調整が必要と説明されています。

しかし、PoCが完全武器化されていないことは、安全を意味しません。

ARM64でマルチテナントKVMを運用している事業者は、優先度を上げて対応する必要があります。

攻撃者に必要な権限

攻撃者は、対象となるARM64 KVMホスト上の仮想マシンを操作できる必要があります。

さらに、GICやITSのMMIOを直接操作するには、ゲストOS内のカーネル権限が必要です。

一般的なクラウドサービスでは、利用者が自分に割り当てられた仮想マシン内でroot権限を持つことがあります。

そのため、クラウド利用者がゲスト内でrootを持つこと自体は、特別な条件ではありません。

一方、通常のWebサイト閲覧者がインターネット経由で直接悪用できる脆弱性ではありません。

攻撃の開始地点は、KVM上で稼働するARM64ゲストです。

どの環境が影響を受けるのか

緊急対応が必要な環境

次の条件を満たす環境は、優先して調査します。

• ARM64またはaarch64サーバー

• KVMホストとして動作

• 未修正カーネルを使用

• ARM64ゲストへvGICv3 ITSを提供

• 信頼できない利用者へ仮想マシンを提供

• マルチテナントクラウド

• CI/CDなどで外部利用者のVMを起動

• ホスティングサービスとしてVMを提供

直接影響を受けない環境

次の環境は、CVE-2026-46316の直接的な影響を受けません。

• x86_64サーバー

• ARM64ではないKVMホスト

• KVMを使用していないARM64サーバー

• Dockerだけを使用しているサーバー

• /dev/kvmがなく、仮想マシンをホストしていない環境

• ARM64 KVMゲストであっても、さらに内部でKVMホストを動かしていない環境

• 修正済みカーネルを使用しているARM64 KVMホスト

発見者も、脆弱性はarch/arm64/kvm/vgic/に存在するため、x86や他のアーキテクチャには影響しないと明記しています。

「x86_64だから無関係」と判断できる理由

理由1：脆弱なソースコードがARM64専用である

脆弱なファイルは次です。

arch/arm64/kvm/vgic/vgic-its.c

arch/arm64/以下は、ARM64向けのLinuxカーネルを構築するときに使用されるコードです。

x86_64向けカーネルでは、対応するアーキテクチャは次です。

arch/x86/

x86_64カーネルに対して、ARM64 KVMのvGIC-ITSコードが実行されることはありません。

理由2：x86_64では割り込みコントローラーの仕組みが異なる

ARM64ではGICが使用されます。

一方、一般的なx86_64環境では、APIC、xAPIC、x2APICなど、別の割り込みコントローラーが使用されます。

したがって、ARM64のvGIC-ITSエミュレーションに存在する不具合は、x86_64のKVM割り込み処理へそのまま影響しません。

理由3：KVMという名前が同じでも内部コードは別である

x86_64にもKVMがあります。

ただし、次のようにアーキテクチャ固有部分は別々です。

KVM
├─ 共通処理
├─ arch/x86/kvm/
├─ arch/arm64/kvm/
├─ arch/riscv/kvm/
└─ その他のアーキテクチャ

「KVMを使用している」というだけでは、CVE-2026-46316の影響対象とは判断できません。

KVMを使用しているかではなく、どのCPUアーキテクチャのKVMを使用しているかが重要です。

「モジュールが読み込まれていない」は主な根拠ではない

元の説明では、「ARM64固有のKVMモジュールが読み込まれていない」ことを根拠としていました。

この表現は補助的には使えますが、主な根拠としては不十分です。

vGIC関連コードは、カーネル構成によっては独立した分かりやすい名前のモジュールとして表示されず、カーネルまたはKVM関連モジュールへ組み込まれる可能性があります。

そのため、次の確認だけで判断してはいけません。

lsmod | grep vgic

出力がなくても、ARM64カーネル内にコードが組み込まれている可能性があります。

確実性の高い確認順序は次です。

1. uname -mでCPUアーキテクチャを確認

2. KVMホストとして動作しているか確認

3. /dev/kvmが存在するか確認

4. 実行中カーネルとベンダーアドバイザリを照合

5. ARM64の場合はvGIC-ITSの利用状況を確認

ELSA-2026-500004とは

ELSA-2026-500004は、Oracle Linux向けのUnbreakable Enterprise Kernelセキュリティ更新です。

2026年7月15日に公開され、重要度は「IMPORTANT」とされています。

この更新には次の3件が含まれています。

修正パッケージは、次の系列です。

6.12.0-204.92.4.3

Oracleは、Oracle Linux 9および10について、aarch64用とx86_64用の両方のUEKパッケージを公開しています。

なぜx86_64パッケージにも同じELSA番号が付くのか

セキュリティアドバイザリは、必ずしも「1件のCVEにつき1パッケージ」とは限りません。

ELSA-2026-500004は、複数の修正をまとめたカーネル更新です。

ELSA-2026-500004
├─ CVE-2026-31663
├─ CVE-2026-46316
└─ CVE-2026-53362

さらに、同じカーネルソースから複数アーキテクチャ向けのパッケージが作成されます。

同じカーネル更新
├─ aarch64パッケージ
└─ x86_64パッケージ

そのため、次の推論は誤りです。

x86_64用パッケージがELSAに掲載されている
        ↓
CVE-2026-46316もx86_64に存在する

正しい読み方は次です。

ELSAには複数のCVEが含まれる
        ↓
一部はARM64固有
        ↓
別のCVEはx86_64にも関係する可能性がある
        ↓
アドバイザリ全体として複数アーキテクチャへ更新を提供

「このCVEは無関係」と「更新不要」は別の判断

kurutann.comがx86_64である場合、CVE-2026-46316は直接影響しません。

しかし、ELSA-2026-500004には別のCVEも含まれています。

したがって、結論は次のように分ける必要があります。

「このCVEは対象外だから、ELSA全体を適用しない」という判断は危険です。

影響判定フロー

CPUアーキテクチャはaarch64か
        │
        ├─ いいえ、x86_64
        │      └─ CVE-2026-46316は直接影響なし
        │
        ▼
KVMホストとして動作しているか
        │
        ├─ いいえ
        │      └─ 攻撃経路なし
        │
        ▼
ARM64ゲストへvGICv3 ITSを提供しているか
        │
        ├─ いいえ
        │      └─ 該当コード経路の露出が限定的
        │
        ▼
信頼できないゲストを稼働させているか
        │
        ├─ いいえ
        │      └─ 悪用可能性は低下
        │
        ▼
修正済みカーネルか
        │
        ├─ はい
        │      └─ 対応済み
        │
        ▼
緊急でカーネルを更新

確認方法1：CPUアーキテクチャを確認する

目的

実行中のLinuxがARM64かx86_64か確認します。

実行場所

調査対象のLinuxサーバーです。

コマンド

uname -m

x86_64の例

x86_64

ARM64の例

aarch64

判断方法

x86_64の場合、CVE-2026-46316の脆弱なARM64コードは実行対象になりません。

aarch64の場合は、KVMホストとして使用しているか続けて確認します。

CPU情報を詳しく表示する場合は、次を実行します。

lscpu

確認する項目は次です。

Architecture:
Virtualization:
Hypervisor vendor:

確認方法2：物理ホストか仮想マシンか確認する

目的

調査対象サーバー自体が、仮想化基盤上のゲストか確認します。

コマンド

systemd-detect-virt

仮想マシンの例

kvm

この出力は「このサーバーがKVMホストである」という意味ではありません。

KVM上で動作するゲストであることを示します。

物理サーバーの例

none

ただし、物理サーバーであることだけでは、KVMホストとして使用しているか判断できません。

確認方法3：KVMホスト機能が利用可能か確認する

目的

対象サーバー上で、さらに仮想マシンを起動できる状態か確認します。

コマンド

if [ -e /dev/kvm ]; then
    echo "/dev/kvm exists"
else
    echo "/dev/kvm does not exist"
fi

KVM利用可能の例

/dev/kvm exists

KVM利用不可の例

/dev/kvm does not exist

/dev/kvmが存在しない場合、通常は対象サーバー上でKVM仮想マシンを作成できません。

VPSがKVMゲストとして動作していても、ネストされた仮想化が許可されていなければ/dev/kvmは公開されません。

確認方法4：KVM関連モジュールを確認する

コマンド

lsmod | grep -E '^kvm'

x86_64・AMD環境の例

kvm_amd
kvm

x86_64・Intel環境の例

kvm_intel
kvm

ARM64環境

ARM64では構成によって表示が異なります。

この結果だけで、vGIC-ITSの影響有無を最終判断してはいけません。

アーキテクチャ、カーネル構成、仮想マシン設定を併せて確認します。

確認方法5：実行中カーネルを確認する

uname -r

Oracle Linux UEKの例です。

6.12.0-204.92.4.3.el10uek.x86_64

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

rpm -q kernel-uek

複数のカーネルが表示される場合があります。

重要なのは、インストール済みだけではなく、現在どのカーネルで起動しているかです。

uname -r

と

rpm -q kernel-uek

の両方を確認してください。

確認方法6：ELSAの適用状態を確認する

目的

ELSA-2026-500004が適用可能か確認します。

コマンド

sudo dnf updateinfo info \
  --advisory ELSA-2026-500004

環境によっては次の形式も使用できます。

sudo dnf updateinfo info ELSA-2026-500004

更新が必要な例

ELSA-2026-500004
Type        : security
Severity    : Important
Status      : update

更新済みの例

Status      : installed

表示形式はDNFとリポジトリのバージョンによって異なります。

次のパッケージ以上が導入されているかも確認します。

kernel-uek-6.12.0-204.92.4.3

対処方法

恒久対策：修正済みカーネルへ更新する

CVE-2026-46316の根本対策は、ベンダーが提供する修正済みカーネルへ更新することです。

Oracle Linuxでは、ELSA-2026-500004で次のUEKが提供されています。

6.12.0-204.92.4.3

ELSAはaarch64とx86_64の両方へ更新パッケージを提供しています。

更新前の注意

カーネル更新では再起動が必要です。

実行前に次を確認してください。

• VPSまたは仮想マシンのスナップショット

• 設定ファイルのバックアップ

• シリアルコンソールや管理コンソールへの接続手段

• 前のカーネルがGRUBに残ること

• 再起動後の監視方法

• メンテナンス時間

• データベースやアプリケーションの正常停止手順

本番サーバーでは、SSH接続だけに依存せず、プロバイダーの管理コンソールから復旧できることを確認してください。

ELSAを指定して更新する

sudo dnf upgrade \
  --advisory ELSA-2026-500004

通常のセキュリティ更新として適用する場合は、次も使用できます。

sudo dnf upgrade --security

更新後、インストールされたカーネルを確認します。

rpm -q kernel-uek

カーネル更新後の再起動

新しいカーネルパッケージをインストールしただけでは、実行中のカーネルは切り替わりません。

計画停止を行い、再起動します。

sudo systemctl reboot

再起動前に、Webアプリケーションやデータベースを安全に停止する必要がある場合は、運用手順に従ってください。

動作確認

1. 新しいカーネルで起動したか確認する

uname -r

期待する例です。

6.12.0-204.92.4.3.el10uek.x86_64

2. 起動失敗がないか確認する

sudo journalctl -b -p warning

前回起動の重大ログを確認する場合は、次を使用します。

sudo journalctl -b -1 -p err

確認項目は次です。

• kernel panic

• module load failure

• filesystem error

• network interface failure

• SELinux denial

• データベース起動失敗

• Webサーバー起動失敗

3. 主要サービスを確認する

sudo systemctl --failed

正常な例です。

0 loaded units listed.

4. Webサービスを確認する

対象サーバー上で確認します。

curl -I https://kurutann.com/

期待する例です。

HTTP/2 200

Cloudflareやリダイレクト構成によっては、301や302が正常な場合もあります。

5. コンテナを確認する

docker ps

またはDocker Composeを使用している場合です。

docker compose ps

すべての必要なコンテナがUpまたはrunningであることを確認します。

暫定対策

ARM64 KVMホストで、すぐにカーネルを更新できない場合は、次の暫定対策を検討します。

信頼できないゲストを停止する

最も確実な暫定対策は、未修正ホスト上で信頼できない仮想マシンを稼働させないことです。

仮想マシンを修正済みホストへ移動する

ライブマイグレーションまたは停止移行を使用し、修正済みカーネルで動作するホストへ移動します。

/dev/kvmへのアクセスを制限する

コンテナや一般ユーザーへ、不必要に/dev/kvmを公開しないでください。

ls -l /dev/kvm

Kubernetesでは、信頼できないワークロードへKVMデバイスを割り当てないようにします。

KVMサービスを停止する

業務上KVMが不要であれば、仮想マシンを停止します。

ただし、仮想マシンの停止はサービス停止につながります。

必ず影響範囲を確認してください。

WAF・IPS・EDRで防げるのか

WAF

WAFでは防御できません。

本脆弱性はHTTPやHTTPS通信ではなく、ARM64ゲストが仮想GIC/ITSのMMIOを操作することで発生します。

Cloudflare WAFやWebアプリケーション向けWAFの検査対象外です。

ネットワークIPS

一般的なネットワークIPSで直接遮断することは困難です。

攻撃の主要部分はゲストOSとホストカーネル内のKVM処理の間で発生し、外部ネットワークパケットとして観測できないためです。

EDR

EDRは補助的な検知に使用できます。

ただし、攻撃がホストカーネル権限へ到達した場合、ユーザー空間のEDRより高い権限で動作される可能性があります。

監視対象の例です。

• 予期しないホストカーネルクラッシュ

• refcountに関する警告

• KASANやslabのエラー

• KVMホスト上の不審なファイル作成

• 仮想マシン稼働中の異常なホストプロセス

• 同一ホスト上の複数VMの同時障害

最優先対策は、カーネルの更新です。

kurutann.comにおける影響評価

kurutann.comの本番VPSでは、実機確認により次のアーキテクチャであることが確認されています。

x86_64

CVE-2026-46316の脆弱なコードは、次のARM64専用コードです。

arch/arm64/kvm/vgic/vgic-its.c

x86_64カーネルでは、このARM64専用処理は実行されません。

そのため、次のように判断できます。

kurutann.comのゲストOSカーネルはx86_64であり、CVE-2026-46316の脆弱なARM64 KVM vGIC-ITSコードを含む実行経路が存在しないため、本脆弱性による直接的な影響はありません。

ただし、これは次の意味ではありません。

ELSA-2026-500004を適用しなくてよい。

ELSA-2026-500004には、CVE-2026-46316以外のカーネル脆弱性も含まれています。

したがって、kurutann.comでは次のように管理します。

CVE-2026-46316
  └─ x86_64のため直接影響なし

ELSA-2026-500004
  └─ 他のCVEを含むため更新対象として確認

カーネル
  └─ 修正版へ更新し、再起動後にバージョン確認

また、VPS基盤となる物理KVMホストのCPUアーキテクチャとカーネル修正状況は、VPS事業者の管理範囲です。

利用者がuname -mで確認できる情報は、自分に割り当てられたゲストOSのアーキテクチャです。

過度な不安を防ぐ脆弱性評価

セキュリティアドバイザリにCVE番号が掲載されているだけで、すべてのサーバーが攻撃可能とは限りません。

脆弱性は、次の順番で評価します。

1. 製品
2. パッケージ
3. バージョン
4. CPUアーキテクチャ
5. カーネル構成
6. 機能の有効・無効
7. サーバーの役割
8. 攻撃者が到達できる経路
9. 必要な権限
10. ベンダー修正の適用状態

CVE-2026-46316では、アーキテクチャとサーバーの役割が特に重要です。

Linuxカーネルを使用
        ↓
それだけでは判定できない

KVMを使用
        ↓
それだけでも判定できない

ARM64 KVMホスト
        ↓
ここで初めて対象候補

vGIC-ITSを提供
        ↓
攻撃経路が成立

未修正カーネル
        ↓
影響対象

このように絞り込むことで、不要な緊急対応を減らし、本当に危険な環境へ対応要員を集中できます。

再発防止

資産台帳にCPUアーキテクチャを記録する

最低限、次の項目を資産台帳へ登録します。

CVEとアドバイザリを分けて管理する

一つのアドバイザリに複数のCVEが含まれることがあります。

管理表では次のように分けます。

VEX形式の考え方を取り入れる

VEXは、製品にCVEが記載されていても、その製品が実際に影響を受けるかを表現する仕組みです。

管理上は、次の状態を区別します。

• affected

• not affected

• fixed

• under investigation

「スキャナーに出た」だけでaffectedと判断しないことが重要です。

カーネル更新後の再起動を管理する

パッケージ更新済みでも、古いカーネルで起動し続けている場合があります。

定期的に次を比較します。

uname -r
rpm -q kernel-uek

必要に応じて、再起動が必要か確認します。

dnf needs-restarting -r

注意点・よくある誤解

LinuxカーネルのCVEだからすべてのLinuxが危険なのか

違います。

Linuxカーネルには、複数のCPUアーキテクチャ、デバイス、ファイルシステム、ネットワーク機能のコードが含まれています。

実際に使用するアーキテクチャと機能によって影響が異なります。

x86_64用RPMが掲載されているからx86_64も脆弱なのか

違います。

一つのカーネル更新に、複数のCVEと複数のアーキテクチャ向けパッケージがまとめられる場合があります。

CVEごとの対象コードを確認してください。

KVMゲストなら危険なのか

通常のKVMゲストであるだけでは、ゲストOS自身がCVE-2026-46316の攻撃対象ホストになるわけではありません。

本脆弱性の攻撃対象は、ARM64ゲストを動かしているKVMホストです。

ただし、ネストされたKVMを動かしている場合は、内側の仮想化ホストとして再評価が必要です。

Dockerを使用している場合も対象か

DockerはKVMとは異なります。

Dockerコンテナだけを動かしており、KVM仮想マシンをホストしていない場合、この脆弱性の攻撃経路は成立しません。

ただし、コンテナへ/dev/kvmを渡している特殊な構成では確認が必要です。

CVSS 9.3と7.0のどちらが正しいのか

どちらかが単純に誤りというわけではありません。

kernel.orgとRed Hatで、攻撃に必要な権限、複雑さ、ゲストからホストへの境界の扱いが異なります。

自社環境では、スコアだけでなく攻撃成立条件を確認してください。

x86_64ならカーネルを更新しなくてよいのか

違います。

CVE-2026-46316は対象外でも、同じ更新に含まれる別のCVEがx86_64へ影響する可能性があります。

アドバイザリ全体を確認してください。

まとめ

CVE-2026-46316は、LinuxカーネルのKVM/arm64にあるvGIC-ITS変換キャッシュの参照カウント処理に存在する脆弱性です。

複数の処理が同じキャッシュエントリを同時に無効化すると、同じ参照を複数回解放し、Use-After-Freeが発生する可能性があります。

発見者が公開したPoCでは、ARM64ゲストからKVMホストへ脱出し、ホストカーネル権限で処理を実行できることが実証されています。

ただし、影響対象は限定されています。

ARM64
  ＋
KVMホスト
  ＋
vGIC-ITS
  ＋
未修正カーネル
  ＋
攻撃者が操作できるゲスト

kurutann.comの本番VPSはx86_64であるため、CVE-2026-46316の脆弱なARM64コードは実行対象になりません。

したがって、ゲストOS側は本脆弱性の直接的な影響対象外です。

一方、ELSA-2026-500004には別のカーネル脆弱性も含まれています。

結論は次のとおりです。

CVE-2026-46316は対象外
        ≠
ELSA-2026-500004は更新不要

脆弱性を正しく評価するには、CVE番号やCVSSだけではなく、CPUアーキテクチャ、サーバーの役割、有効な機能、攻撃経路、修正状態を突き合わせる必要があります。

FAQ

Q1. CVE-2026-46316はリモート攻撃ですか

一般的なインターネット越しのリモート攻撃ではありません。

攻撃者は、対象ARM64 KVMホスト上のゲスト仮想マシンを操作できる必要があります。

Q2. ゲスト内の一般ユーザーだけで攻撃できますか

公開された研究では、GIC/ITSのMMIOを操作するために、ゲストカーネル権限が必要とされています。

ゲスト内の一般ユーザー権限しかない場合は、別の権限昇格脆弱性との組み合わせが必要です。

Q3. x86_64のKVMホストは影響を受けますか

CVE-2026-46316については影響を受けません。

脆弱なコードはARM64専用です。

ただし、x86_64 KVMには別のCVEが存在する可能性があるため、カーネル更新は継続してください。

Q4. ARM64サーバーでもKVMを使用していなければ安全ですか

本脆弱性のゲストからホストへの攻撃経路は成立しません。

ただし、修正済みカーネルへ更新することを推奨します。

Q5. ELSA-2026-500004のx86_64版を適用する必要はありますか

CVE-2026-46316だけを理由にすれば不要ですが、ELSAには他のCVEも含まれています。

アドバイザリ全体として更新を評価してください。

Q6. 再起動は必要ですか

カーネル更新後、新しいカーネルを有効にするには原則として再起動が必要です。

Q7. WAFやCloudflareで防げますか

防げません。

攻撃はゲストとKVMホストカーネルの間で発生します。

Q8. 脆弱性スキャナーに表示されたらどうすればよいですか

次の順番で確認します。

1. uname -m

2. uname -r

3. systemd-detect-virt

4. /dev/kvmの有無

5. KVMホストとしての利用状況

6. ベンダーアドバイザリ

7. 修正カーネルの適用状態

参考情報

• NVD：CVE-2026-46316の説明、CVSS、修正コミット一覧。

• Linux Kernel公式KVM APIドキュメント。

• Linux Kernel公式ARM VGICv3ドキュメント。

• Red Hat VEX：CVE-2026-46316の影響、CWE、CVSS、製品状態。

• Oracle Linux ELSA-2026-500004。

• 発見者によるITScape技術資料およびPoC。

一次資料リンク

• NVD - CVE-2026-46316
• Oracle Errata ELSA-2026-500004