Linux脆弱性PwnEscape、ホストメモリ漏えいの仕組みと修正パッチ

自分で借りているVPSやクラウドのサーバーが、Linuxカーネルのネットワーク処理経由で乗っ取られる――2026年10月中旬、そんな見出しを見た人もいるだろう。脆弱性の名前は「PwnEscape」、深刻度を示すCVSSスコアは10点満点中9.3。¹ 見出しの言葉だけを追うと、契約しているVPSやクラウドが今にも危ないように読める。

確認してみると、話はもう少し具体的だった。Linuxカーネル本体にはすでに修正パッチが入っている。² AWSとさくらインターネットは対象サービスを公表し、対応を始めている。³⁴ どこまでが確認された事実で、自分は何をすればいいのか。

何が起きる可能性があるのか

PwnEscapeは、仮想マシン(VM)とそれを動かすホストの間にある、ふだん意識しない境界を突く脆弱性だ。VPSやクラウドの多くは、1台の物理サーバー(ホスト)の上でKVMという仕組みが複数のVMを動かす。各VMには「virtio-net」という仮想のネットワークカードが割り当てられる。AWSのセキュリティ速報によると、この経路に欠陥がある。パッチ未適用のカーネル4.4〜6.18を動かすKVM環境では、ゲストVM内の攻撃者が細工したパケットを送るだけで、ホスト側のカーネルメモリを壊せる可能性がある。

攻撃に使われるのは「チェックサムオフロード」という、本来はネットワークカードが担う処理をソフトウェア側に肩代わりさせる仕組みだ。ゲストはcsum_startとcsum_offsetという2つの数値を使って、パケットのどこからチェックサムを計算するかを指定できる。Openwall oss-securityへの投稿は、この2つの数値がホスト側で十分に検証されないまま使われていたと説明する。投稿者はJan Schaumann氏、報告はPWNAI ResearchのPaulos Yibelo氏によるものだ。では、この数値の書き換えだけで、なぜホストのメモリが外へ漏れるのか。

ヘッダー書き換えで何が漏れるか

IPv4のパケットには、ヘッダーがどこまでかを示す「IHL」という項目がある。通常の値は20バイトだ。oss-securityへの投稿によれば、攻撃者はこのcsum_start/csum_offsetを細工できる。その結果、検証後に遅延実行される関数(skb_checksum_help())の書き込み先を操作でき、IHLの値そのものが書き換わる。ヘッダー長の解釈は20バイトから60バイトへ変わる。本来なら送られるはずのなかったホストメモリの断片が、その差の範囲でパケットに混ざり、外部へ送信されてしまう。投稿は、この方法で約32バイトのホストメモリが漏れたと報告している。

つまり、パケットの「どこまでがヘッダーか」という解釈そのものを、ゲスト側が外から書き換えられてしまうということになる。自分が意外だったのは、書き換えられるのがcsum_startとcsum_offsetというたった2つの数値だけだという点だ。もっと複雑な手順が要るものだと思っていた。

20バイトのはずの区切りが60バイトまで伸び、その差の中に本来出て行かないデータが乗る。棒の長さの差がそのまま、ゲストが外から書き換えられる範囲の大きさを表している(Openwall oss-securityへの投稿による)。

では、ここまでで分かった「メモリが漏れる」という話と、報道にある「ホストでコードを実行できる」という話は、同じ確からしさで確認されているのだろうか。

「VM脱出」はどこまで確認されたか

Publickeyの記事は、研究者の検証環境でホスト側Linux OSでのコード実行まで到達したと「説明されている」と書いている。これはPWNAI ResearchのPaulos Yibelo氏が、自分の所有するKVM環境で確認したという報告だ。oss-securityへの投稿自身も、本番環境での実行は主張しておらず、詳細な技術情報の第2部は未公開だと明記している。独立した第三者による検証は、現時点では確認できていない。

一方、AWSの公式速報が確定した影響として説明しているのは「ホストのカーネルメモリを破損させ、ホストメモリの漏えいやサービス拒否を引き起こす可能性」だ。コードの実行までは書いていない。自分は最初、CVSS 9.3と「VM脱出」という言葉だけで身構えていたが、AWSの文面を読み直すとそこまでは書かれていないと分かった。見出しが示す「VM脱出」の確からしさは、情報源によって一段階違う。つまり、メモリが漏れるという仕組みはAWSも認める確定した範囲で、その先の「コードを実行できる」は研究者の検証環境にとどまる報告だ。

修正自体はこの区別とは関係なく、もう動いている。

修正パッチはすでに本体に入った

oss-securityへの投稿によれば、修正コミット6785011f8b16が2026年10月8日にLinuxカーネルのネット関連ツリー(net.git)へ適用された。コミット名は「ipv4: validate checksum_start before completing checksum」という。10月14日には、Linus Torvalds氏のメインラインへマージされている。作者はRed HatのMichael S. Tsirkin氏だ。include/net/ip.hにip_check_csum_start()という検証用のヘルパー関数を追加した。チェックサムを完了する前に値を検証する、5か所の呼び出し元を保護する仕組みだ。投稿はこれを「多層防御(defense in depth)」の措置と位置づけている。トランスポート層のフィールドが後から変更される懸念など、より広い範囲の検証は今後の課題として残っている。

カーネル本体への修正は完了した。では、自分が契約しているクラウドやVPSは、この修正をもう取り込んでいるのだろうか。

AWSとさくらの対応状況

確認できた範囲では、2社の対応は利用形態によって分かれている。

AWSのセキュリティ速報は、EC2・Lambda・Fargateのようにホストの管理をAWSが担うサービスは、影響を受けないと明記している。一方、virtio-netとKVMを使って仮想マシンを自分で管理している利用者には、回避策がないとしている。更新済みカーネルへの更新が必要になる。該当するバージョンは、Amazon Linux 2ならkernel-4.14.355-287.750.amzn2など、Amazon Linux 2023ならkernel-6.1.188-233.385.amzn2023などだ。

さくらインターネットの発表は、さくらのVPSとレンタルサーバ・マネージドサーバの新規申し込みを一時停止したと案内している。一方、パッチの適用予定日はまだ示していない。専用サーバのようにOSを利用者自身が管理するサービスについては、事業者側の一律対応はない。利用しているディストリビューションのセキュリティ情報を確認し、必要な更新を行うよう求めている。

自分がどちらに該当するかは、次の基準で判断できる。

• AWSのEC2・Lambda・Fargateを使っているだけなら、対応は不要
• 自分でKVM/virtio-net環境を構築・管理している(Firecrackerを含む)なら、使っているディストリビューションの修正済みカーネルへ更新する
• さくらのVPS・クラウド・レンタルサーバの利用者は、公式発表ページの更新を継続して確認する
• 専用サーバなどでOSを自分で管理している場合は、使っているディストリビューション(Amazon Linux、Ubuntu、Debianなど)のセキュリティ情報を確認し、カーネルを更新する

まとめ

「PwnEscape」と名付けられたLinuxカーネルの脆弱性は、virtio-net経由のチェックサムオフロードを悪用する。ゲストVMがIPv4ヘッダーの解釈を書き換え、ホストメモリの一部をパケットに漏らせるというものだった。「ホストでコードを実行できる」という報道の一部は、研究者自身の検証環境での報告にとどまる。AWSが確定した影響として認めているのは、メモリの漏えいとサービス拒否までだ。修正コミットはすでに2026年10月14日にLinuxカーネルのメインラインへマージされている。AWSのEC2・Lambda・Fargateのような管理サービスの利用者に、対応は要らない。一方、自分でKVM/virtio-netを運用している場合や、さくらのVPS・専用サーバなどを使っている場合は、各社の発表を確認しながらカーネルを更新する必要がある。