Copy Fail 技術解説: CVE-2026-31431 の AF_ALG、splice、page cache

4月 29, 2026

Copy Fail における AF_ALG、splice、page cache の技術イラスト

Copy Fail、CVE-2026-31431 は、Linux カーネルのローカル権限昇格脆弱性です。短く言えば、AF_ALG、splice()、暗号テンプレート authencesn、そして algif_aead の in-place 最適化が組み合わさり、page cache に対する制御された 4 バイト書き込みが可能になります。セキュリティチームにとって重要なのは、派手な説明ではなく、書き込み可能な宛先を共有すべきでない scatterlist 間で境界が破れたという点です。

重要な部品は AF_ALG です。これはカーネルの暗号機能を userspace から使えるようにする socket インターフェースです。splice() を使うと、userspace はファイルから pipe へデータを移動できますが、全バイトを通常のコピーとして扱うわけではありません。その経路で、カーネルは page cache のページへの参照を保持できます。これらのページが、暗号サブシステムから宛先として扱われる scatterlist に連結されると危険な状態になります。

Xint Code の分析によれば、authencesn は ESN に関連するバイトを並べ替えるため、宛先バッファの一部を一時領域として使います。この動作は元の前提では自然でした。しかし、数年前に導入された AF_ALG AEAD の in-place 経路と組み合わさることで、一時的な書き込みが正当な領域を越え、読み取り可能なファイルのメモリ上コピーに到達するようになりました。

page cache が影響を変える理由

page cache は攻撃者プロセスだけの private copy ではありません。システムの他の経路も読む可能性があるメモリ上の表現です。そのコピーが setuid binary に対応している場合、ディスク上の永続ファイルを変更しなくても、一時的なメモリ変更が実行に影響する可能性があります。そのため、物理ファイルだけを確認するチェックでは影響を十分に判断できません。

報告されている変更は小さく、1回あたり 4 バイトです。しかし、サイズだけで深刻度は決まりません。小さくても信頼性が高く、繰り返し可能な primitive は、対象が重要であれば十分に危険です。Copy Fail の技術的な価値は、PoC のサイズではなく、制御性、信頼性、影響を受ける kernel や distribution 間での移植性にあります。

これが深刻度の議論にもつながります。この問題はローカル実行を必要とし、リモートからの初期アクセスを与えません。そのため、複数の vendor は medium または moderate と扱っています。一方、multi-tenant、CI、コンテナ、sandbox 環境では、「local」と「critical」の境界は薄くなります。これらの基盤は、まさにローカルコード実行を提供しているからです。

修正内容

主な修正は、algif_aead を out-of-place 動作に戻すことです。page cache のページを連結した複合構造を source と destination が共有する代わりに、入力 scatterlist と出力 scatterlist を分離します。これにより、authencesn の一時書き込みがファイル由来のメモリへ届く条件がなくなります。

運用者にとっての結論は明確です。fix を含む distribution kernel に更新してください。独自 kernel を管理し、検証プロセスを持つチームでない限り、個別 commit の手動取り込みは避けるべきです。通常の環境では、vendor の kernel package、AMI/base image、または cloud provider が管理する kernel が修復単位です。

一時的な mitigation として、Copy Fail のサイトは algif_aead の無効化や、信頼できない workload に対する AF_ALG socket 作成のブロックを推奨しています。runner や sandbox では妥当な攻撃面削減ですが、検証が必要です。一部の embedded 環境や明示的な暗号 offload 設定では AF_ALG に依存している可能性があります。

防御側のチェックリスト

まず、distribution 名だけでなく実際の kernel を棚卸しします。kernel version、backport、cloud build は製品名より重要です。次に、ユーザー、コンテナ、CI job が kernel を共有する host を特定します。これらは単一ユーザーの server より優先されます。

三つ目に、sandbox policy が不要な socket family をブロックしているか確認します。多くの workload は AF_ALG を開く必要がありません。第三者コードを実行する基盤では、未使用の面を閉じることで、このインシデント以外にもリスクを下げられます。四つ目に、外部コード用 runner を分離し、低信頼の PR や pipeline に特権 host を再利用しないことです。

五つ目に、vendor advisory で確認します。公開議論には有用な情報がありますが、公開ページで議論された存在しない RHEL バージョンへの言及など、誤りや不一致も含まれます。変更管理では、公式 tracker と platform ごとの記録を基準にしてください。

パッチで解決しないこと

Copy Fail を修正しても、共有 kernel 上で信頼できないコードを実行するという根本問題は消えません。強い分離、syscall 制御、tenant 分離、base image のローテーションも不要にはなりません。技術的な教訓はより広いものです。userspace からの zero-copy 経路が存在する場合、異なる由来の参照を混ぜる in-place 最適化は慎重に監査する必要があります。

platform team は、splice()、page cache、userspace に公開される暗号 API、まれな syscall を許す sandbox の回帰テストを見直すべきです。Copy Fail は、ある時点では妥当だった判断が、別のサブシステムの変更によって数年後に危険化することを示しています。

結論はパニックではなく優先順位です。CI、multi-tenant Linux、Kubernetes、共有 desktop、開発 host など、攻撃者候補がすでにローカルコードを実行できる場所では、信頼性の高いローカル権限昇格は二次的な問題ではありません。信頼境界の破れです。