CVE-2026-99999（PwnEscape）とは｜さくらが新規受付を止めたLinuxカーネル脆弱性と確認手順

CVE-2026-99999（通称 PwnEscape）は、Linux カーネルの IPv4 処理でチェックサムの位置情報を確かめずに使い、ホストのネットワークヘッダを書き換えてしまう欠陥です。仮想マシンのゲストが細工したパケットを送ると、ホストのメモリが漏れ、条件がそろえばホストでのコード実行に至ると報告されました。カーネルの CNA は CVSS 3.1 で 9.3 を付けています。10月16日、さくらインターネットはこの脆弱性を理由に、さくらのクラウドの新規プロジェクト作成とレンタルサーバ・マネージドサーバの新規申し込みを止めました。修正版の一覧と、利用者が自分の環境で確かめる手順をまとめます。

OSS の脆弱性を追う当サイトの全体像は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 にあります。さくらインターネットの8月の事案は さくらインターネット不正アクセスとは｜第三報の951と136万・2023年4月からの期間・自分の確認手順 で扱った別の出来事で、今回の告知はそれとの関係に触れていません。カーネルのネットワーク処理の欠陥としては、7月の Fraggap解説｜LinuxカーネルIPv6のOOB書き込みでroot昇格するCVE-2026-53362 が近い型です。

CVE-2026-99999 の時系列——2008年のコードから10月16日のさくらの告知まで

CVE の公表日は10月15日（日本時間の夜）です。時刻は日本時間で、カーネル側はコミットと CVE レコードの時刻、さくら側は告知の日付です。

6.6.159・6.1.190・5.15.223・5.10.272 は、前の版との差が今回の修正を含む3件だけの臨時の安定版です（4系列とも差を数えて確認）。7.2・6.18・6.12 は通常の安定版にまとめて入りました。

何が起きたか——PwnEscape は KVM ではなくホストの IPv4 処理の欠陥

仮想マシンは送信するフレームに「チェックサムはまだ計算していない。この位置から計算して、この位置に書け」という情報（virtio-net のヘッダ）を添えられます。ホストの VMM はそれを TAP デバイスに書き、ホストのカーネルが IPv4 として処理します。パケットを断片化する ip_do_fragment() が skb_checksum_help() でチェックサムを埋めるとき、開始位置が IP ヘッダの内側を指していても止めませんでした。そのため、検証済みのヘッダ長（IHL）が書き換わり、断片を作る処理がバッファの外のホストメモリを IP オプションとしてゲストに送り返します。CVE レコードの CVSS の根拠欄がこの経路を書いています。

修正コミット 6785011f8b16 は、include/net/ip.h に ip_check_csum_start() を足し、チェックサムを埋める前に開始位置が IP ヘッダより後ろにあるかを確かめます。同じ確認を、ブリッジの netfilter、nfnetlink_queue、xt_CHECKSUM、xfrm_output にも入れました。コミットの説明は「入口でのもっと完全な検証は準備中」としており、今回の修正は多層防御の一段です。

Fixes: は2本あります。1本は tun（VMM が使う経路）、もう1本は packet ソケットのオフロード対応（bfd5f4a3d605）です。CVSS の攻撃元が「ネットワーク」ではなく「ローカル」なのは、インターネットから届くパケットでは起きず、ゲストかローカルのプロセスが細工する必要があるためです。packet ソケット側からホストのメモリまで届くかは、当サイトでは未検証です。

実証の範囲は報告元で書き方が違います。

さくらインターネットの対応——サービスごとの告知と確かめられた範囲

当サイトの環境からは sakura.ad.jp・cloud.sakura.ad.jp・help.sakura.ad.jp のいずれも接続を拒否され、ページを直接開けませんでした。以下は検索エンジンに載った本文と見出しによるもので、原文の一字一句は確かめていません。

告知は、なぜ新規の受付だけを止めたのか、どの基盤が影響を受けるのかを書いていません。当サイトも推測しません。利用者がいまやることは次のとおりです。

・既存の契約はそのまま動くと告知されている。解約や移行を急ぐ根拠は、告知には無い
・クラウドと VPS のゲストは、自分のカーネルを配布元の修正版に上げる（ゲスト自身を守る分。ホストはこれでは直らない）
・ホストメンテナンスの個別案内が届くよう、会員情報の連絡先メールを確認する
・専用サーバ PHY で KVM などの仮想マシンを動かしているなら、自分がホストの立場になる。次の節の修正版へ
・レンタルサーバは利用者が触れる OS が FreeBSD で（8月の記事で確認）、カーネルの更新は利用者の手が届かない。さくらの続報を待つ

対策——修正版カーネルの一覧と、ホストとゲストそれぞれがやること

上流の修正版は次の7系列です。CVE レコードの記載と、安定版ツリー（gregkh/linux の GitHub ミラー）のタグを git で取り寄せて、各タグに修正コミットが入っていること、一つ前のタグには入っていないことを確かめました。

mainline を 7.3-rc7 とするのは CVE レコードの記載で、rc への取り込みは当サイトでは確かめていません。5.4 など上流の保守が終わった系列には修正版がありません。

やることは立場で分かれます。

配布元のカーネル（Ubuntu の 6.8.0 系、RHEL 系の 5.14.0 系など）は上流の版番号を使わないので、配布元のセキュリティ情報で修正パッケージを確かめます。修正版が出るまでの緩和策として、CloudLinux は信頼できないゲストのチェックサムオフロードを切ることと非特権ユーザー名前空間を止めることを「部分的」として挙げ、Red Hat は基準を満たす緩和策は無いとしています（どちらも検索インデックス経由。当サイトでは未検証）。オフロードを切ると性能に響くので、試すなら検証環境から始めてください。

自システム確認コマンド——CVE-2026-99999 の版と TAP の経路を見る

当サイトのセキュリティ記事は確認コマンドを git fetch --all --prune から始めていますが、今回は付けません。調べる対象がリポジトリの依存ではなく、いま動いているカーネルだからです。ファイルの検索の代わりに、版と /sys の中身を読みます。

# 1. 動いているカーネル・配布元・仮想化の種類（none なら物理、kvm などならゲスト）
uname -r
uname -v
systemd-detect-virt
# 入っているカーネル（新しいものが入っていても、再起動するまで uname -r は古いまま）
ls -1 /boot/vmlinuz-*
dpkg -l 'linux-image*' | grep '^ii'   # Debian / Ubuntu
rpm -q kernel                         # RHEL / Alma / Rocky / Amazon Linux

# 2. 上流の版番号を使うカーネルを、系列ごとの修正版と比べる
pwnescape_check() {
  v=${1:-$(uname -r)}; base=${v%%[-+_]*}
  br=${base%.*}; p=${base##*.}
  case $br in
    7.2) fix=11;; 6.18) fix=57;; 6.12) fix=113;; 6.6) fix=159;;
    6.1) fix=190;; 5.15) fix=223;; 5.10) fix=272;;
    *) echo "$v: 上流の安定版の系列ではない。配布元の告知で判断"; return 2;;
  esac
  if [ "$p" = 0 ]; then echo "$v: x.y.0 は配布元の番号。uname -v の版で判断"; return 2; fi
  if [ "$p" -ge "$fix" ]; then echo "$v: 上流の修正版 $br.$fix 以上"
  else echo "$v: 上流の修正版 $br.$fix 未満"; return 1; fi
}
pwnescape_check
# Debian 12 は uname -v の版で比べる
pwnescape_check "$(uname -v | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -n 1)"

# 3. ゲストのフレームを受け取る TAP があるか（vnet_hdr あり＝今回の経路を持つホスト）
for f in /sys/class/net/*/tun_flags; do
  [ -e "$f" ] || { echo "TAP/TUN デバイスなし"; break; }
  n=$(basename "$(dirname "$f")"); fl=$(cat "$f")
  if [ $(( fl & 0x4000 )) -ne 0 ]; then echo "$n: vnet_hdr あり"; else echo "$n: vnet_hdr なし"; fi
done

2つ目の関数は、偽の版番号19通りで判定を確かめました。7系列それぞれの修正が無い最後の版（7.2.10〜5.10.271）は「未満」、修正版ちょうど（7.2.11〜5.10.272）は「以上」、Debian 12 の 6.1.0-28-amd64 は「uname -v で判断」、Ubuntu の 6.8.0-87-generic と RHEL 系の 5.14.0-570.el9.x86_64 は「配布元の告知で判断」と出ます。Debian 13 の 6.12.48+deb13-amd64 は上流の版を含むので「未満」、6.12.113+deb13-amd64 なら「以上」になります。uname -v に版が出ない環境では、最後の行は uname -r での判定と同じ結果になります。配布元が修正だけを先に取り込んでいる場合もあるので、「未満」は「修正前の可能性がある」の意味で読んでください。

3つ目は陽性対照として、IFF_VNET_HDR を付けた TAP と付けない TAP を1つずつ作って走らせ、前者だけが「vnet_hdr あり」（tun_flags は 0x5002）、後者が「なし」（0x1002）と出ることを確かめました。TAP を閉じた後は「TAP/TUN デバイスなし」です。macvtap は tun_flags を持たないとみられ、この方法では拾えません（未検証）。

検証に使った当サイトのクラウドのコンテナは uname -r が 6.18.44-fc-v139、systemd-detect-virt が docker で、関数は「6.18.57 未満」と返しました。これはゲスト側の版で、ホストの状態は分かりません。利用者の手元で測れるのはこの範囲までです。dpkg -l は実行できましたがカーネルのパッケージは入っておらず、/boot も空でした。rpm -q kernel は RPM 系の環境が無く未実行です。

影響範囲——CVE-2026-99999 で危ないのは誰か、版だけでは言えないもの

影響を受ける条件は、修正前のカーネルが、信頼できない側から来たチェックサム情報つきのパケットを IPv4 として断片化・処理することです。

版だけで言えないものが2つあります。配布元の独自番号のカーネルは、配布元がどのパッケージで修正したかを見るまで判断できません。もう一つはホストの状態で、利用者の手元からは測れません。さくらを含むクラウドの利用者は、事業者のホストメンテナンスの告知が届いた時点で初めて「ホストが直った」と言えます。

参照ソース

・CVE-2026-99999 の CVE レコード（CVEProject/cvelistV5）（直接取得。影響範囲・修正版・CVSS と根拠欄。2026-10-16）
・torvalds/linux の修正コミット 6785011f8b16（直接取得。git fetch で本文と Fixes: を確認）
・gregkh/linux（安定版ツリーの GitHub ミラー）（直接取得。7系列のタグに修正コミットが入っていることを git log で確認）
・Ubuntu Security: CVE-2026-99999（直接取得。優先度と各リリースの状態。2026-10-16）
・【重要】Linuxカーネルの脆弱性（CVE-2026-99999）に関する当社サービスへの影響について（接続拒否。検索インデックスの本文で確認）
・さくらのクラウドにおけるLinuxカーネルの脆弱性（CVE-2026-99999）への対応状況について（接続拒否。検索インデックスの本文で確認）
・さくらのレンタルサーバ・マネージドサーバ新規申し込み受付停止のお知らせ（接続拒否。検索インデックスの本文で確認）
・Findings from the $1M Vercel Sandbox challenge（Vercel）（接続できず。CVE レコードが参照。内容は検索インデックス経由）
・PwnEscape（pwn.ai）（接続できず。CVE レコードが参照する発見者の解説）
・Red Hat: CVE-2026-99999・CloudLinux のブログ（接続拒否。検索インデックス経由で緩和策の記載を確認）