CVE-2026-31431「Copy Fail」対応まとめ

2026年4月末、Linux カーネルに CVE-2026-31431「Copy Fail」が公開されました。

Xint / Theori の研究チームが発見・命名した脆弱性で、ローカルの非特権ユーザーがカーネルのページキャッシュに制御された 4 バイトを書き込める、というものです。

PoC も公開されており、共有サーバーや CI 環境を運用しているなら他人事ではないので整理しておきます。

概要

項目	内容
CVE	CVE-2026-31431
通称	Copy Fail
種別	Linux カーネルのローカル権限昇格
影響箇所	`crypto/algif_aead`、`authencesn`、`AF_ALG`、`splice()`
攻撃条件	ローカルの非特権ユーザー権限
CVSS	7.8 High（kernel.org / Ubuntu / GitHub Advisory）、5.5 Medium（Amazon Linux）
公開日	2026-04-23（Ubuntu セキュリティページ）、技術記事は 2026-04-29

CVSS の数字はベンダーによって評価が割れていますが、Ubuntu は理由を “Trivial local privilege escalation” と書いています。

スコアより実態で判断するべきで、後述しますがかなり高優先で扱うべき内容です。

なにが起きているか

AF_ALG ソケットと splice() を組み合わせることで、非特権ユーザーがカーネルのページキャッシュ上のファイルに 4 バイトの書き込みができます。

ここで重要なのが「ページキャッシュへの書き込み」という点です。ディスク上のファイルは書き換わりません。

カーネルがメモリ上に持っているキャッシュだけが変わります。

これが何を意味するかというと、オンディスクのチェックサム比較では検知できない可能性があります。

この 4 バイト書き込みを繰り返すことで、setuid-root バイナリのページキャッシュを改変し、次にそのバイナリが実行されたとき root 権限で任意のコードを動かす攻撃につながります。

技術的な原因

根本は 2017 年に algif_aead.c に入った in-place 処理の最適化です。

この変更により、splice() 経由で渡されたページキャッシュ由来のページが、書き込み可能な scatterlist 側に連結される構造になりました。

authencesn は復号処理中に scratch 領域として出力バッファの境界外に 4 バイトを書き込む挙動を持っており、この境界外書き込みが AF_ALG の in-place 処理と splice() によるページキャッシュ参照と組み合わさって、ページキャッシュを書き換えられる状態になっていました。

修正の内容は “Revert to operating out-of-place”、つまり 2017 年の最適化を元に戻す形です。

まさかの、9年もの間発見されなかった脆弱性で、AIによって発見されて界隈がざわついたとのことです。

影響を受ける環境

2017 年以降にビルドされたパッチ未適用のカーネルが対象です。

直接検証された環境として Ubuntu 24.04 LTS、Amazon Linux 2023、RHEL 10.1、SUSE 16 が挙げられています。

特に注意が必要なのはここです。

複数ユーザーが同じカーネルを共有する開発サーバー、踏み台、共有シェル環境
CI ランナー、ビルドサーバー、self-hosted GitHub Actions / GitLab Runner / Jenkins agent
Kubernetes / コンテナ基盤
VPS、クラウド VM

コンテナ環境だと、ページキャッシュはホスト上で共有されます。そのため、コンテナ内からホスト全体、ひいては同一ノード上の他コンテナへと影響が広がる可能性があります。Xint / Theori は「container escape primitive」と表現しています。

個人の VPS で自分しか使わないなら攻撃条件を満たしにくいですが、誰かが入り込んでいた場合は話が変わります。

自分で管理している Linux サーバーがあるなら確認しておくべきです。

VPS 契約したら、とりあえず ssh ポートは変えておけ | Lazy Developer

この記事では、VPS を契約した直後に最低限やっておきたい ssh のポート変更と、ufw を使ったファイアウォール設定について備忘録として記載します。サーバーをインターネットに公開すると、SSH への不正アクセス試行やブルートフォース攻撃は普通に飛んできます。 22 番のまま運用していると、とにかく雑なアクセス試行

lazy-developer.jp

対応方針

カーネル更新が本命

根本対策は修正済みカーネルへの更新です。

Xint / Theori も “Patch the kernel” を最優先推奨としています。

# Ubuntu / Debian 系
sudo apt update && sudo apt upgrade

# RHEL / Amazon Linux 系
sudo dnf update kernel

# 更新後、再起動して起動中カーネルを確認
uname -r

再起動して実際に修正済みカーネルが動いているか uname -r で確認するまでが対応完了です。

ただ、本番環境を操作するときは関係者への周知と調整は必須ですよ。

algif_aead を無効化する（暫定）

すぐにカーネルを更新できない場合、algif_aead モジュールを無効化する暫定策があります。

sudo sh -c 'echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf'
sudo rmmod algif_aead 2>/dev/null || true

ただし落とし穴があります。

algif_aead がモジュールではなくカーネル組み込み（CONFIG_CRYPTO_USER_API_AEAD=y）になっている環境では、この緩和策が効きません。

エンタープライズ系カーネルの一部ではここが builtin になっているケースが指摘されています。

↓↓↓確認方法↓↓↓

zgrep CONFIG_CRYPTO_USER_API_AEAD /proc/config.gz /boot/config-$(uname -r) 2>/dev/null
lsmod | grep algif_aead || true

lsmod にヒットしないかつ CONFIG_CRYPTO_USER_API_AEAD=y なら、モジュール無効化での緩和はできません。

その場合はカーネル更新を急ぐしかないです。

コンテナ / CI 環境では AF_ALG の制限も検討

コンテナや CI 実行基盤では、seccomp で AF_ALG ソケット作成を制限する暫定策もあります。

ただし seccomp プロファイルの適用範囲や既存ワークロードへの影響は環境依存で、Kubernetes では Pod Security Standards や RuntimeDefault seccomp だけで十分かどうかを検証する必要があります。

CVSSより実害で優先度を判断する

Amazon Linux が 5.5 Medium としているせいか、「Medium ならしばらく待てばいい」という判断をしてしまいそうになりますが、それは危ないです。

今回高優先で扱う理由を並べると、

ローカルの非特権ユーザーから root につながる
PoC が公開されている
共有ホスト、CI、コンテナ基盤では一点突破でノード全体に影響が出る
ページキャッシュ改変のため、オンディスクの検査では見逃す可能性がある
2017 年以降の広いカーネル範囲が対象

CVSS の数字はスコアリングの観点が違うだけで、攻撃のしやすさや影響範囲は数字だけでは語れないです。

先日の axios のサプライチェーン攻撃もそうでしたが、「スコアが中程度だから後回し」という判断がそのまま被害につながるケースが増えています。

axios の npm サプライチェーン攻撃で起きたことと守り方 | Lazy Developer

2026年3月31日、週間1億DLを超える axios の npm パッケージが乗っ取られ、マルウェア入りバージョンが公開されました。何が起きたのか、影響確認の方法、そして lockfile と npm ci による防御策を整理します。