はじめに
Linuxカーネルの脆弱性 Copy Fail（CVE-2026-31431） が公開されました。
この脆弱性は、一般ユーザーからroot権限へ昇格できる ローカル権限昇格（LPE: Local Privilege Escalation） です。
特に印象的なのは、単に「rootが取れる」という点だけではありません。
- ファイルを永続的に書き換えない
- ページキャッシュ上の内容を利用する
- コンテナやCIのような共有カーネル環境で危険度が高い
という点がかなり厄介です。
この記事では、実際の挙動を3枚のスクリーンショットで確認しつつ、Copy Failの仕組みをできるだけ本質から整理します。
注意: 本記事は防御・理解を目的とした解説です。詳細な再現手順やPoCコードの掲載は行いません。検証は必ず自分が管理する環境、または明示的に許可された環境でのみ行ってください。
何が起きるのか
Copy Failを利用すると、通常ユーザーの状態からroot権限へ昇格できます。
ざっくり言うと、次のようなことが起きます。
- 通常ユーザーでは
sudoが使えない - 脆弱性を利用する処理を実行する
-
suなどを通じてroot権限を得られる
つまり、外部から直接侵入するタイプの脆弱性ではなく、すでにローカルでコードを実行できるユーザーがrootへ昇格するタイプの脆弱性です。
デモ
1. 実行前: 通常ユーザーであり、sudoも失敗する
まず、通常ユーザーであることを確認します。
whoami の結果は user であり、sudo echo hello も失敗しています。
この時点では、当然root権限はありません。
2. 脆弱性を利用する処理を実行する
次に、検証用環境で脆弱性を利用する処理を実行します。
詳細なコマンドやコードは安全のため掲載しません。
ここで重要なのは、ディスク上のファイルを普通に書き換えているわけではない、という点です。
3. 実行後: root権限を取得している
処理後に su を実行し、再び状態を確認します。
whoami の結果が root になっており、sudo echo hello も成功しています。
このように、通常ユーザーからroot権限へ昇格できていることが分かります。
Copy Failの本質
ディスク上のファイルと、実際に実行時に参照されるメモリ上の内容は、必ずしも同じものではない。
Linuxでは、ファイルを読み込むときに毎回ディスクへアクセスするわけではありません。
一度読み込まれたファイルの内容は、メモリ上の ページキャッシュ に置かれます。
通常、このページキャッシュはディスク上のファイル内容と整合しているべきですが、
Copy Failではここにズレが生じます。
関係する要素（技術的核心）
authencesn — 根本原因となった暗号テンプレート
Copy Failの直接の原因は、Linuxカーネルの暗号テンプレート authencesn に存在するロジックバグです。
authencesn は認証付き暗号（AEAD）の一形式で、暗号化と認証タグの検証を組み合わせる仕組みです。
2017年のコミット（72548b093ee3）で、処理効率化のため「入力と出力に同じスキャッターリストを使う」最適化が導入されました。
この最適化の副作用として、出力スキャッターリストが入力側（ページキャッシュ上）のページへの参照を保持したまま連結される構造になりました。
その結果、authencesn がシーケンス番号の並べ替え処理のためにスクラッチ領域へ4バイトを書き込む際、
本来は出力バッファに書くべき内容が、連結されたページキャッシュ上のページへ届いてしまいます。
GCM・CCM・通常の authenc といった他のAEADアルゴリズムは出力バッファの範囲内に収まるよう実装されており、
この問題が発生するのは authencesn 固有の挙動です。
AF_ALG — ユーザー空間からカーネル暗号APIへの入口
AF_ALG は、ユーザー空間からLinuxカーネルの暗号APIを利用するためのソケットインターフェースです。
Copy Failでは、攻撃者がこのインターフェース経由で authencesn テンプレートを呼び出します。
AF_ALG 自体に脆弱性があるわけではなく、authencesn のバグへ到達するための経路として使われます。
splice() — ページキャッシュへの橋渡し
splice() は、ファイルディスクリプタ間でデータをカーネル内部で直接移動するシステムコールです。
ユーザー空間を経由しないゼロコピーに近い設計が特徴です。
Copy Failでは、splice() を使って対象ファイルのページキャッシュを AF_ALG ソケットに接続します。
これにより、authencesn が書き込むスクラッチ領域が、対象ファイルのページキャッシュ上に重なる状態が作られます。
ページキャッシュ
ページキャッシュは、ディスク上のファイル内容をメモリ上に保持する仕組みです。
カーネルはバイナリを実行する際にページキャッシュを参照するため、
ディスク上のファイルを変更しなくても、ページキャッシュ上の内容を書き換えるだけで
実行されるバイナリの挙動を変えることができます。
何が危険なのか
1. ローカルユーザーがrootになれる
この脆弱性は、リモートから直接攻撃できるタイプではありません。
しかし、すでにローカルでコードを実行できる状態であれば、一般ユーザーからrootへ昇格できる可能性があります。
特に以下の環境で危険です。
- 共有開発サーバー
- CI runner
- Kubernetesノード
- SaaSのサンドボックス環境
2. コンテナ環境でも問題になり得る
コンテナはカーネルを共有するため、カーネル脆弱性はコンテナ境界を越える可能性があります。
3. 検知が難しい
ディスク上のファイルを変更しないため、単純なハッシュチェックでは検知が困難です。
Dirty Pipe / Dirty Cowとの比較
似た系統の脆弱性として、Dirty Cow（CVE-2016-5195）やDirty Pipe（CVE-2022-0847）を思い出す人も多いと思います。
これらに共通するのは、
ファイルそのものではなく、ページキャッシュ側に作用する
という点です。
ただし、Copy Failは先行する2つと比べて、攻撃の信頼性が大きく異なります。
Dirty Cowはコピーオンライト処理のレースコンディションを突く必要があり、タイミング依存で再現性が低く、
場合によってはシステムをクラッシュさせるリスクもありました。
Dirty Pipeはパイプバッファの状態操作に依存し、影響範囲が特定のカーネルバージョンに限定されていました。
一方でCopy Failはレース条件が不要なロジックバグであり、
ディストリビューション依存の調整もほぼ不要です。
公開PoCは非常に小さく、標準ライブラリのみで動作するため、
「どの環境でも同じように動く」という点が大きな特徴です。
対策
影響を受けるバージョン
Linux カーネル 4.14 以降の未パッチバージョンが対象です。
6.18.22 未満の 6.18 系、6.19.12 未満の 6.19 系などが該当します。
パッチ状況（2026年時点）
- Ubuntu / Debian / SUSE: 修正済みカーネル提供済み
- Red Hat / AlmaLinux: 順次反映中
推奨対策
- カーネルを最新版へ更新
- AF_ALGの利用制限（seccompなど）
- 不信頼コードの実行環境を分離
まとめ
Copy Failは、Linuxカーネルの設計における「最適化と安全性の境界」を突いた脆弱性です。
- ファイルは安全でもメモリは安全とは限らない
- カーネル機能の組み合わせが思わぬ経路を作る
この2点は、今後のシステム設計でも非常に重要な視点になると思います。