Firecrackerの復元VMでメモリ分離に脆弱性 1.16.2への更新とUffdの条件を確認

Firecrackerで、スナップショットから復元したmicroVMのゲスト内rootユーザーが、条件次第で仮想マシンモニターのプロセスメモリを読み書きできる脆弱性CVE-2026-122192が公表されました。自前の実行基盤でFileメモリバックエンドとballoonまたはvirtio-memを組み合わせる運用は、1.16.2または1.17.0以降へ更新してください。

AWSの11月4日付告知（2026-169-AWS）は、AWS Lambdaを含むAWSサービスは影響を受けず、顧客の対応は不要としています。本稿の対象はFirecracker自体を運用する事業者です。Webサービスの隔離実行、利用者コードを実行するジョブ、開発用サンドボックスなどでmicroVMを管理している場合、ゲストの更新だけでなくホスト側の実行基盤を確認する必要があります。

影響はバージョンと復元方式とメモリ機能で絞る

11月8日に確認した開発元のセキュリティ勧告では、影響版は0.23.0から1.16.1までです。ただし、その範囲の全VMで無条件に発生するわけではありません。Fileメモリバックエンドでスナップショットから復元され、balloonまたはvirtio-memデバイスを持つVMで、ホストがメモリの置換マッピングに失敗する条件が重なった場合に問題となります。

攻撃に必要なのはゲスト内のroot権限です。ネットワークから認証なしで直接ホストを操作する脆弱性との説明はありません。一方、顧客やジョブにゲスト内rootを渡す基盤では、その権限を許可していること自体を安全の根拠にできません。ゲスト内で許した管理権限が、隔離の外側にあるFirecrackerプロセスのメモリへ届く可能性が問題です。

スナップショットを使わずに起動したVMと、Uffdメモリバックエンドで復元したVMは本件の影響を受けないと勧告は説明しています。したがって、バージョン番号だけの検索に加え、実際の起動・復元経路を確認してください。同じサービス内でも、初回起動と高速復元で異なる方式を選んでいるなら、確認対象を分けます。

深刻度はHighで、開発元のCVSS 3.1基本値は7.5です。スコアにはローカルからの攻撃、高い権限、複雑な条件が反映されています。ただし、複数の利用者の処理を隔離する基盤では、前提条件が運用上成立しているかを先に評価すべきです。参照した告知に実環境での悪用確認は記載されていません。悪用がないと証明された意味ではありません。

失敗後に処理を続けることがメモリ境界を崩す

問題は、不要になったゲストメモリを破棄し、対応するマッピングを置き換える処理にあります。置換に失敗するとゲストメモリ領域の一部が未マッピングのまま残り、その状態でFirecrackerが動作を続ける可能性があります。後から同じ領域に確保されたFirecracker側のメモリが、ゲスト内rootから読み書きできる状態になり得ます。

修正では、破棄したメモリを置換するときに元のMAP_NORESERVEフラグを維持し、置換マッピングに失敗した場合はプロセスとVMを終了させます。異常を検出しても継続する動作から、無効なメモリ状態での継続を止める動作へ変わる点が重要です。ホスト全体のroot取得や別VMへの侵入が必ず成功する、とまで公式資料は説明していません。

運用上は、更新後の終了を単なる可用性の後退として扱わないことも必要です。本サイトとしては、VMの異常終了を検知したら同じ要求を無制限に再試行するのではなく、該当ジョブ、ホストのメモリ状況、復元方式を照合する運用を提案します。安全側で終了した原因を調べずに再生成を繰り返すと、障害の切り分けが難しくなります。

更新は実行中のVMMとスナップショットの互換性まで確認

修正先は1.16.2と1.17.0です。1.16.2のリリースノートには関連するメモリ処理の修正に加え、スナップショット形式の変更が記載されています。1.16.2で作ったスナップショットは1.16.0・1.16.1で読み込めず、逆方向も読み込めません。更新バイナリーの配置だけでなく、復元に使う状態ファイルとの組み合わせを移行計画に含めてください。

以下は本サイトからの適用確認案です。まず、サービス起動定義やデプロイ定義からFirecrackerの実行パスと版を収集します。複数ホストへ配布する仕組みなら、保管しているバイナリーと、現在動いているプロセスが同じ版かを分けて確認します。旧プロセスが残る構成では、ディスク上のファイルを差し替えただけで修正が適用されたとは判断できません。

次に、スナップショット復元の設定、FileかUffdかというメモリバックエンド、balloon・virtio-memの有無を資産一覧に追記します。テンプレートの既定値だけでなく、実際にVMを作るワーカーが送信する設定を確認します。実行基盤がFirecrackerを内部で利用する場合は、その製品の提供元が修正を取り込んだ版を確認し、独自に内部バイナリーだけを置換する運用は避けます。

検証環境では、修正版で使用できるスナップショットを準備し、通常の復元、アプリケーションの起動、メモリ返却処理、終了と再実行を確認します。ここで確認するのは更新後の運用成立性です。本稿では脆弱性を再現する攻撃試験を実施しておらず、通常の動作確認だけで脆弱性が再現しないことを証明できるとはしていません。

切り戻しでは、修正版で作ったスナップショットを旧版へ戻せない場合を想定します。本サイトとしては、バイナリー、スナップショット、起動設定を対応関係が分かる単位で管理し、旧版へ戻す判断には脆弱性が再び残ることも含めるよう提案します。派生実装やフォークを保守する場合は、版名が新しいかだけでなく対応する修正が含まれることを確認します。

Uffdの暫定策はバックエンド名の変更だけでは完了しない

更新できない場合、AWSはUffdメモリバックエンドを使うスナップショット復元を案内しています。ただし、Firecracker 1.16.2のUffd公式資料にある破棄済みページの処理要件を満たすことが前提です。ページフォールト処理をカーネルに任せる方式から、ユーザー空間の専用ハンドラーと連携する方式へ変わります。

公式資料では、ページフォールトハンドラーを実装する責任は利用側にあります。balloonによるメモリ解放時のUFFD_EVENT_REMOVEを識別し、解放後のページをゼロ化する必要があります。その後に同じページでフォールトが起きたときも、元のスナップショットファイルから内容を戻すのではなく、ゼロ化したページとして扱うことが求められます。

jailerを使う場合、ハンドラープロセス、Unixドメインソケット、メモリファイルをjail内に配置し、ソケットへのアクセスをFirecrackerとハンドラーに限定する条件もあります。ホストのuserfaultfdへのアクセス権限も確認対象です。単にUffdを指定して復元が開始できたことだけで、これらの要件を満たしたとは判断できません。

ハンドラーが復元途中で停止すると、Firecrackerは必要なページを待ち続けて停止状態になる可能性があります。公式資料はハンドラーの状態監視や、必要に応じた再生成の仕組みを求めています。本サイトとしては、復元の所要時間、ハンドラーの終了、VMの応答を別々に監視し、停止したVMを切り離す手順まで確認してから暫定策を採用するよう提案します。

overcommitとOOM設定は補助対策として扱う

AWS告知は既知のホストメモリ条件への対策として、Linux 6.12のovercommit処理変更を含まないカーネルではvm.overcommit_memory=0を使い、最大破棄サイズをホストのRAMとswapの合計以下に保つこと、メモリcgroupのOOM killerを有効に保つことを挙げています。一方、これらがすべての置換マッピング失敗を防ぐとはしていません。

したがって、overcommit値を変更したことを修正済みの判定条件にはできません。ホスト全体へ影響する設定でもあるため、カーネルの版と配布元の変更、RAM・swap、cgroupの設定を確認し、同居ワークロードへの影響を評価してください。公式の条件を確認せずに、本番のカーネルパラメーターを一律変更する手順は推奨しません。

判断の順序は、まず影響する復元経路の特定、次に修正版への移行です。移行を待つ場合はUffdの実装要件を満たせるかを判断し、補助的なホスト設定だけで済ませないようにします。ゲスト内rootを持つ処理を隔離して実行する運用では、ゲストの更新、VMMの更新、スナップショットの互換性を別々の確認項目として残すことが、適用漏れを防ぐ実務上の要点です。

復元に失敗した際は、版の不一致とページ供給の停止を切り分けます。旧スナップショットだけで失敗するなら、まずリリースノートの形式互換性を確認します。Uffdへ変更した構成だけで待ち続けるなら、ハンドラーが生存しているか、ソケットとメモリファイルへ到達できるか、破棄通知を処理しているかを確認します。いずれも本サイトが提案する調査順であり、特定のエラー文を本件の侵害証拠とするものではありません。

本番展開の完了記録には、対象ホスト、稼働するVMMの版、復元方式、利用するスナップショットの作成版、通常処理の確認結果を残します。未更新ホストへジョブが戻る仕組みがあれば、その経路も確認します。修正の取り込みとサービスの復旧を別々に判定すれば、動作を戻すために気付かず旧版へ戻してしまう事態を避けやすくなります。