【CVE-2026-53362】Linux IPv6 Frag Escapeを解説―一般ユーザーからroot・コンテナ脱出につながるfraggap脆弱性

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

【CVE-2026-53362】Linux IPv6 Frag Escapeを解説―一般ユーザーからroot・コンテナ脱出につながるfraggap脆弱性

冒頭文

CVE-2026-53362は、LinuxカーネルのIPv6送信処理に存在する、メモリーサイズの計算不備です。

特定のUDPv6送信処理を実行すると、カーネルが確保した領域を越えてデータを書き込み、重要な管理情報であるskb_shared_infoを破壊する可能性があります。

本脆弱性は、インターネットから特殊なIPv6フラグメントを送り付けるだけで成立する、未認証リモート攻撃ではありません。

主な攻撃者は、対象Linux上でコードを実行できるローカルの一般ユーザーです。

しかし、「ローカル攻撃だから危険性が低い」とは限りません。

Red Hatは、コンテナ内の一般ユーザーが本脆弱性を悪用し、ホストOSへ脱出してroot権限を取得できる可能性があると説明しています。

結論・要点

kernel.orgとOracleは、CVSS 3.1を7.8と評価しています。攻撃条件はローカル、必要権限は低、利用者操作は不要で、機密性・完全性・可用性はいずれもHighです。

この記事で分かること

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

• CVE-2026-53362で何が起きるのか
• 外部からのIPv6攻撃ではない理由
• fraggapとskbの意味
• メモリーサイズの計算を誤った仕組み
• 一般ユーザーからrootへ到達できる理由
• コンテナ脱出との関係
• 影響するカーネルバージョン
• Oracle Linuxでの確認方法
• カーネル更新と再起動方法
• 暫定対策と注意点
• WAF・IPS・EDRで防御できる範囲

対象読者・前提環境

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

• Linuxサーバーを管理している人
• Oracle LinuxやRHELを運用している人
• DockerやPodmanを使用している人
• KubernetesやOpenShiftを運用している人
• 複数利用者へLinux環境を提供している人
• CI/CDで信頼できないコードを実行している人
• 脆弱性スキャナーでCVE-2026-53362を検出された人

用語と全体像

skbとは

skbはsk_buffの略です。

簡単にたとえると、Linuxカーネルがネットワークパケットを運ぶために使う配送箱です。

箱の中には、IPv6ヘッダーやUDPデータなどが格納されます。

Linuxカーネルの公式ドキュメントでは、sk_buffはパケットを表す主要なネットワーク構造体とされています。データ領域の末尾には、追加の断片情報などを管理するskb_shared_infoが配置されます。

┌─────────────────────────────────────────┐
│ skbのメモリー                            │
├─────────┬───────────┬───────────────────┤
│ headroom│ パケットデータ │ skb_shared_info │
└─────────┴───────────┴───────────────────┘

skb_shared_infoとは

skb_shared_infoは、パケットデータの断片や共有状態などを管理する領域です。

配送箱に貼られた「中身の管理ラベル」にたとえられます。

パケットデータが境界を越えてこの管理ラベルを書き換えると、カーネルが誤ったメモリーをデータとして扱う可能性があります。

fraggapとは

fraggapは、IPv6パケットを複数のskbへ分けて構築するときに、前のskbから次のskbへ引き継ぐ必要があるデータ量です。

単純な「ネットワーク上のフラグメント間にある空白」ではありません。

MSG_MOREとは

MSG_MOREは、「まだ続きのデータを送るので、すぐに送信を確定しないでほしい」とカーネルへ伝える送信フラグです。

UDPでも複数回の送信データを一つのデータグラムとしてまとめるために使用できます。

MSG_SPLICE_PAGESとは

MSG_SPLICE_PAGESは、ページ単位のデータを、なるべくコピーせずソケットバッファへ追加するためのカーネル内部の処理に関係します。

Linuxカーネルには、ページをskbへ追加し、コピーを減らす共通処理が存在します。

何が起きたのか

問題は、Linuxカーネルの次の関数にありました。

__ip6_append_data()

この関数は、送信するIPv6パケットへデータを追加します。

特定の条件でページを利用した割り当て経路へ入ると、修正前のコードは必要なサイズを次の考え方で計算していました。

alloclen = fragheaderlen + transhdrlen;
pagedlen = datalen - transhdrlen;

しかし、datalenには既にfraggapが含まれていました。

一方、通常のメモリー領域であるalloclenには、fraggap分が加算されていませんでした。

その結果、次の状態になります。

確保した通常領域 ＝ 必要量よりfraggap分だけ小さい

ページ領域       ＝ fraggap分だけ大きく計算される

前のskbから引き継いだデータを新しいskbへコピーすると、確保した領域を越え、後ろにあるskb_shared_infoへ書き込んでしまいます。

問題の全体像

なぜ外部からのIPv6パケット受信攻撃ではないのか

問題の関数は、受信パケットを再構築する関数ではなく、送信パケットへデータを追加する関数です。

攻撃者は、対象Linux上でUDPv6ソケットを作成し、特定の送信処理を実行する必要があります。

公式CVE情報でも、低権限ユーザーがUDPv6ソケットでMSG_MOREとMSG_SPLICE_PAGESを使用して問題を発生させられると説明されています。

したがって、次の説明は誤りです。

インターネット上の攻撃者
    ↓
細工したIPv6フラグメントを送信
    ↓
受信しただけで侵害

正しい攻撃経路は次です。

対象Linux内の一般ユーザー
または侵害済みコンテナ内のプロセス
    ↓
ローカルでUDPv6ソケットを操作
    ↓
カーネルメモリー破壊
    ↓
root権限やホスト権限を取得

なぜ一般ユーザーからrootへ到達できるのか

書き越される場所は、単なるアプリケーションのデータ領域ではありません。

Linuxカーネルがネットワークバッファを管理するskb_shared_infoです。

攻撃者がメモリー破壊を制御できる場合、カーネルが参照するページ情報などを不正な値へ変更できる可能性があります。

Red Hatは、この問題を任意のカーネルメモリー読み書きへつなげ、次の操作が可能になると説明しています。

• プロセスの認証情報を上書きする
• root権限を取得する
• SELinuxによる制御を回避する
• コンテナからホストへ脱出する

自分の環境に関係するか

優先して対応すべき環境

次の環境では優先度が高くなります。

• 影響を受けるLinuxカーネルを使用している
• IPv6がカーネルで有効
• 複数の一般ユーザーがログインする
• Docker、Podman、Kubernetesを使用している
• 信頼できないコンテナを実行する
• CI/CDで外部コードを実行する
• Webアプリケーションがコンテナ内で動作する
• rootlessコンテナやユーザー名前空間を使用する

直接的な攻撃可能性が低い環境

次の環境では直接的な攻撃可能性は下がります。

• 修正済みカーネルで起動している
• IPv6機能を含まないカーネルである
• ローカルユーザーやコンテナが存在しない
• 信頼できないコードを一切実行しない
• 非特権ユーザーが必要な名前空間を作成できない

ただし、公開Webアプリケーションに別のRCEが存在した場合、そのRCEを入口としてCVE-2026-53362を悪用される可能性があります。

影響するカーネルバージョン

kernel.orgのCVE情報では、上流カーネルの修正版として次のバージョンが示されています。

NVDでは、Linuxカーネル6.0以降の該当系列が、各修正版より前の場合に影響を受ける構成として登録されています。

ただし、ディストリビューションは修正コードを古いバージョンへバックポートすることがあります。

Oracle Linuxでは、上流の6.12.95ではなく、UEKの次のパッケージとして修正されています。

6.12.0-204.92.4.3

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

目的

現在、どのカーネルで起動しているか確認します。

実行場所

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

コマンド

uname -r

出力例

6.12.0-204.92.4.3.el10uek.x86_64

判断方法

Oracle Linux UEKの場合、ELSA-2026-500004で提供された修正版以上か確認します。

パッケージをインストールしただけで、再起動していない場合、uname -rには古いカーネルが表示されます。

確認方法2：インストール済みカーネルを確認する

rpm -q kernel-uek

出力例です。

kernel-uek-6.12.0-204.92.4.3.el10uek.x86_64

複数表示された場合は、古いカーネルと新しいカーネルが併存しています。

uname -rと比較し、新しいカーネルで実際に起動しているか確認してください。

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

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

修正更新が未適用の場合、更新可能なパッケージが表示されます。

更新済みの場合は、インストール済みとして表示されるか、更新対象が表示されません。

OracleのELSA-2026-500004には、CVE-2026-53362の修正を含むUEK 6.12.0-204.92.4.3が登録されています。

確認方法4：IPv6のカーネル設定を確認する

grep '^CONFIG_IPV6=' \
  "/boot/config-$(uname -r)"

正常な出力例です。

CONFIG_IPV6=y

この場合、IPv6機能がカーネルへ組み込まれています。

ファイルが存在しない環境では、次を試します。

zgrep '^CONFIG_IPV6=' /proc/config.gz

IPv6が有効なだけで、直ちに侵害されているわけではありません。

カーネルバージョンと修正状態を併せて確認します。

確認方法5：ユーザー名前空間を確認する

Red Hatが示す既知の攻撃経路では、ネットワーク名前空間を作成できることが重要です。

sysctl user.max_user_namespaces

出力例です。

user.max_user_namespaces = 65534

ゼロより大きい場合、ユーザー名前空間の作成が許可されています。

ただし、この値だけで悪用可能と断定はできません。

対処方法

修正済みカーネルへ更新する

Oracle Linuxでは、次のコマンドでELSAを指定できます。

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

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

sudo dnf upgrade --security

更新前の注意事項

カーネル更新前に次を確認します。

• VPSスナップショット
• データベースのバックアップ
• Dockerボリュームのバックアップ
• プロバイダーの管理コンソール
• SSH以外の復旧手段
• GRUBに旧カーネルが残ること
• メンテナンス時間
• 主要サービスの停止手順

再起動

カーネルパッケージを更新しただけでは、修正版は有効になりません。

sudo systemctl reboot

再起動後、次を確認します。

uname -r

動作確認

カーネル確認

uname -r
rpm -q kernel-uek

起動失敗確認

sudo systemctl --failed

正常例です。

0 loaded units listed.

カーネルログ確認

sudo journalctl -b -p warning

次のような異常がないか確認します。

• kernel panic
• general protection fault
• page fault
• slab corruption
• network driver error
• Docker起動失敗

Docker確認

docker ps
docker compose ps

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

Webサイト確認

curl -I https://kurutann.com/

構成に応じて、200、301、302などの想定した応答を確認します。

暫定対策

Red Hatは、修正カーネルをすぐに適用できない場合の一時的な攻撃面削減策として、非特権ユーザー名前空間の無効化を案内しています。

sudo sysctl -w user.max_user_namespaces=0

再起動後も維持する場合です。

echo 'user.max_user_namespaces = 0' |
  sudo tee /etc/sysctl.d/99-disable-userns.conf

注意

この設定は次の機能を壊す可能性があります。

• rootless Podman
• 一部のアプリケーションサンドボックス
• ユーザー名前空間を利用する開発ツール
• 一部のコンテナ処理

Red Hatも、根本修正ではなく攻撃面を減らす回避策と説明しています。可能な限りカーネル更新を優先してください。

WAF・IPS・EDRによる補助対策

WAF

Cloudflare WAFやWebアプリケーション向けWAFでは直接防御できません。

脆弱性はHTTPリクエストの解析ではなく、Linuxホスト内のUDPv6送信処理で発生します。

ネットワークIPS

外部ネットワーク上の悪意あるIPv6フラグメントを遮断するだけでは、本脆弱性の根本対策になりません。

攻撃操作はローカルのソケット処理として実行されます。

EDR・コンテナランタイム監視

次の挙動は補助的な監視対象になります。

• 一般ユーザーによる大量の名前空間作成
• コンテナ内の予期しないUDPv6操作
• コンテナからホスト側ファイルへのアクセス
• プロセス認証情報の不自然な変化
• SELinux設定の異常変更
• カーネルクラッシュ
• /proc/sys配下の予期しない変更

ただし、攻撃者がカーネル権限を取得すると、ユーザー空間のEDRを回避できる可能性があります。

根本対策はカーネル更新です。

kurutann.comにおける影響評価

kurutann.comはDockerコンテナを使用しています。

そのため、一般利用者へSSHアカウントを発行していなくても、Webアプリケーションの別の脆弱性によってコンテナ内コード実行を奪われた場合、CVE-2026-53362がホスト脱出の二段目に利用される可能性があります。

本番環境へELSA-2026-500004を適用し、再起動後の実行中カーネルが修正済みであることを確認できている場合、次のように記載できます。

kurutann.comの本番VPSには、CVE-2026-53362を修正するELSA-2026-500004を適用しました。カーネル更新後にサーバーを再起動し、実行中カーネルが修正版へ切り替わっていることを確認しています。完全なパッケージ情報とコマンド出力は、内部の変更管理記録へ保存しています。

次の3点を証跡として残します。

1. ELSA-2026-500004がインストール済み
2. kernel-uek修正版がインストール済み
3. uname -rが修正版カーネルを示している

再発防止

カーネル更新後の再起動を確認する

uname -r
rpm -q kernel-uek

インストール済みカーネルと実行中カーネルを比較します。

コンテナの権限を最小化する

• --privilegedを使用しない
• 不要なLinux Capabilityを削除する
• ホストの/procや/sysをマウントしない
• 不要なデバイスをコンテナへ渡さない
• rootlessとrootfulの構成差を管理する
• 信頼できないイメージを実行しない

資産台帳へカーネル情報を記録する

注意点・よくある誤解

IPv6ポートをファイアウォールで閉じれば安全か

本脆弱性は、外部から特定ポートへ接続する攻撃ではありません。

ローカルのUDPv6ソケット操作が起点です。

IPv6アドレスを公開していなければ安全か

公開IPv6アドレスの有無だけでは判断できません。

IPv6機能がカーネル内で利用可能であり、ローカルユーザーが該当処理を実行できるかが重要です。

ローカルユーザーがいないから安全か

Dockerコンテナ内のプロセスも、ホストカーネルを共有しています。

Webアプリケーションが侵害されると、攻撃者がローカルコード実行環境を得る可能性があります。

カーネルを更新しただけで対応完了か

再起動していなければ、古いカーネルが動き続けます。

必ずuname -rを確認してください。

NVDのスコアは7.8なのか

NVD自身の評価は未設定ですが、kernel.orgのCNAスコアとして7.8が掲載されています。Oracleも7.8としています。

まとめ

CVE-2026-53362は、LinuxカーネルのIPv6送信処理で、fraggap分のメモリーを正しく確保できていなかった脆弱性です。

低権限ユーザーが特定のUDPv6送信処理を実行すると、パケットデータがskbの境界を越え、skb_shared_infoを書き換える可能性があります。

UDPv6送信
   ↓
fraggap分の確保漏れ
   ↓
領域外書き込み
   ↓
skb_shared_info破壊
   ↓
カーネルメモリーの読み書き
   ↓
root権限昇格・コンテナ脱出

本脆弱性は、外部から悪意あるIPv6フラグメントを受信するだけで成立するリモート脆弱性ではありません。

一方で、コンテナ内コード実行からホストOSへ脱出できる可能性があるため、DockerやKubernetesを運用する環境では重要です。

Oracle Linuxでは、ELSA-2026-500004を適用し、再起動後に実行中カーネルを確認してください。

FAQ

CVE-2026-53362はリモート攻撃ですか

直接的にはローカル攻撃です。

攻撃者は対象Linuxまたはコンテナ内でコードを実行できる必要があります。

一般ユーザーでも悪用できますか

公式評価では、低い権限を持つローカルユーザーから実行可能です。

Dockerコンテナから悪用できますか

必要な名前空間操作が可能な場合、コンテナからホストへ脱出できる可能性があります。Red Hatが公式にコンテナ脱出の影響を説明しています。

IPv6を使用していなければ更新不要ですか

推奨されません。

カーネル更新には他の脆弱性修正も含まれます。ELSA全体として更新を評価してください。

Cloudflare WAFで防げますか

防げません。

ホスト内部のカーネル処理で発生するためです。

再起動は必要ですか

原則として必要です。

新しくインストールしたカーネルを有効にするには、再起動してuname -rを確認します。

参考情報

• NVDおよびkernel.org CNAのCVE情報。
• Oracle Linux CVE情報。
• Oracle Linux ELSA-2026-500004。
• Red Hat IPv6 Fragmentation Container Escape Bulletin。
• Linux Kernel sk_buff公式ドキュメント。
• Linux Kernel Networking API。