この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
そう聞いた瞬間、背筋が凍りました。
2026年4月29日、Theori社の Taeyang Lee 氏が、AI支援セキュリティ監査ツール「Xint Code」で発見したカーネル脆弱性を公開しました。CVE-2026-31431、通称「Copy Fail」。CVSS 3.1 で 7.8(HIGH)。Linuxカーネル crypto/algif_aead モジュールに2017年から潜んでいた論理バグです。
影響範囲は 5.10〜6.19 系列のほぼ全主流カーネル。Ubuntu、Debian、RHEL、SUSE、Amazon Linux、Fedora、Arch。要するに、現役で動いているLinuxサーバーのほとんどが該当します。20年以上Linuxサーバーの運用に関わってきましたが、ここまで「広く・浅く・確実に」影響する脆弱性は久しぶりです。本稿では、現役のサーバー管理者目線で、出社したら真っ先に本番機で何を確認・実行するかを書きます。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
CVE-2026-31431「Copy Fail」とは何か
3行でまとめると、こうなります。・Linuxカーネル crypto/algif_aead モジュールの authencesn 処理に、in-place 最適化の論理バグがある
・AF_ALG ソケットと splice() を組み合わせると、page cache に対して4バイトの任意書き込みができる
・SetUIDバイナリ(例: /usr/bin/su)を汚染して、ローカルの一般ユーザーから root が取れる
公式情報の整理は以下です。
・CVE番号: CVE-2026-31431
・通称: Copy Fail
・公開日: 2026-04-29(一部報道は4-30付)
・CVSS 3.1: 7.8 HIGH(AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H、kernel.org / CERT-EU 評価)
・発見者: Theori社 Taeyang Lee 氏 / AI監査ツール Xint Code
・公式サイト: https://copy.fail/
・PoCリポジトリ: https://github.com/theori-io/copy-fail-CVE-2026-31431
PoC は 732 バイトの Python スクリプト。標準ライブラリのみで動き、外部依存ゼロ。Theori が検証した Ubuntu 24.04 / Amazon Linux 2023 / RHEL 10.1 / SUSE 16 で、いずれも 100% 成功。
「ローカルから root を取る」は、現場では「すでに一般アカウントを取られた段階」を前提とします。SSH総当たり、Web経由のRCE、委託メンバーの端末経由、入口はいくらでもある。そこから root に昇格できれば、サーバーは事実上相手のものです。
なぜ732バイトでrootが取れるのか
AF_ALG は、Linuxカーネルがユーザー空間に公開している「暗号機能用のソケット型インターフェース」です。AF_ALG ソケットを開けば、AES や SHA、AEAD(認証付き暗号)にデータを直接流し込めます。今回バグがあったのは AF_ALG 配下の algif_aead(AEAD処理用モジュール)です。歴史的経緯がポイントです。2017年 Linux 4.14 で commit 72548b093ee3 が入り、AEAD処理の性能改善のために「in-place 最適化」が導入されました。req->src(入力)と req->dst(出力)が同じ scatterlist を指す、つまり「同じメモリを読みつつ書く」モードです。メモリコピーが減り、確かに速い。
ここに splice() を組み合わせると話が変わります。splice() は内部的に page cache のページを直接 scatterlist にマップする仕組みなので、攻撃者の視点では次が成立します。
・SetUIDバイナリ(例: /usr/bin/su)を read-only で開いて page cache に乗せる
・splice() でそのページを algif_aead の入出力 scatterlist に食わせる
・in-place 最適化が走り、read-only であるはずの page cache に4バイトを書き戻す
・page cache 上の su が改竄され、次に su が exec された瞬間にメモリへロードされる
・root として任意コードが実行される
4バイトでも、x86_64命令を1〜2個書き換えれば認証チェックを飛ばすには十分です。修正コミット a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5(mainline 7.0)はこの in-place 最適化を revert し、out-of-place に戻しました。「2017年の最適化を諦めて安全な実装に戻す」というのが今回のパッチです。
「これ、CTFみたいですね」と言われたら、確かにそうだと思います。732バイトに収まるから、恐ろしいです。
影響を受けるディストロとカーネルバージョン一覧
「うちは大丈夫だろう」と思っているサーバーが、ほぼ確実に該当します。Theori の検証によれば、影響範囲は実運用上は 5.10 〜 6.19 系列のほぼ全主流カーネル。歴史的混入は Linux 4.14(2017年)。4.14以降で algif_aead を有効にしたビルドは原則すべて該当です。パッチ済バージョン(Theori / oss-security 一次情報)は以下のとおり。
| カーネル系列 | パッチ済の最初のバージョン |
|---|---|
| 5.10系(LTS) | 5.10.254 以降 |
| 5.15系(LTS) | 5.15.204 以降 |
| 6.1系(LTS) | 6.1.170 以降 |
| 6.6系(LTS) | 6.6.137 以降 |
| 6.12系 | 6.12.85 以降 |
| 6.18系 | 6.18.22 以降 |
| 6.19系 | 6.19.12 以降 |
| mainline | 7.0 以降(コミット a664bf3d603d) |
・Ubuntu 20.04〜24.04: 影響あり、一部で修正未提供(公開時点)。Ubuntu 26.04 以降は影響外
・Amazon Linux 2023(kernel 6.18.8系): ALAS で CVE 受領済、修正提供は順次
・RHEL 10.1(kernel 6.12系): ステータス未確定
・SUSE 16(kernel 6.12系): 修正未提供
・Debian / Fedora / Arch / Rocky / AlmaLinux / Oracle Linux: 影響あり、各ディストロの通告で個別追跡
LTSを真面目に使っている運用者ほど、カーネルは 5.10系・5.15系・6.1系・6.6系のどれかに該当する可能性が高い。Ubuntu 22.04/24.04 LTS、RHEL 9系、Rocky 9系、Amazon Linux 2023、みんな影響圏内です。CERT-EU 表記は4-30時点のスナップショットなので、本番に当てる前に必ず各ディストロの通告で最新状態を再確認してください。
自社サーバーが踏むか確認する3コマンド
長い話を読んでもらった後で恐縮ですが、これは今すぐ対応してください。所要時間は1台あたり30秒あれば充分です。1. uname -r で現行カーネルを確認する
まず、走っているカーネルのバージョンです。$ uname -r 5.15.0-119-generic
2. dmesg で algif 関連のロード状況を確認する
algif_aead モジュールがブート時に何かエラーを吐いていないか、ざっと見ます。$ sudo dmesg | grep -i -E "(algif|af_alg|crypto)"
3. lsmod | grep algif で読み込み状態を確認する
algif_aead が現在カーネルにロードされているかを確認します。$ lsmod | grep algif algif_aead 16384 0 af_alg 32768 1 algif_aead
当日打てる緩和策
カーネル更新と再起動が確実なのは前提として、本番機の再起動枠は即決できない現場が多い。ここでは再起動なしで打てる緩和策を3つ、優先順に並べます。1. algif_aead モジュールを blacklist する
該当モジュールを今後ロードさせない設定です。# /bin/false にエイリアスして、ロードを拒否させる $ echo "install algif_aead /bin/false" | \ sudo tee /etc/modprobe.d/disable-algif-aead.conf # 既にロードされていれば、解除する $ sudo rmmod algif_aead
注意点として、dm-crypt や LUKS、wireguard、IPsec など、AEAD系暗号処理を使う一部機能が間接的に algif_aead を必要とする場合があります。本番に当てる前に、検証環境で「OS起動 → ログイン → 業務サービス起動」までが正常に走るかを確認してください。私はまずステージング3台に当てて1日様子を見てから、本番へ展開しました。
2. AF_ALG ソケット自体を制限する
特定サービス単位で縛るなら、systemd unit に RestrictAddressFamilies を入れて AF_ALG を含めないのが定石です。[Service] RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
3. apt update / yum update / dnf update で取れる範囲を取る
各ディストロのパッケージリポジトリで、Copy Fail 対応カーネルが配布され始めている場合は、まずそれを取り込みます。# Ubuntu / Debian $ sudo apt update $ apt list --upgradable | grep linux-image $ sudo apt install --only-upgrade linux-image-generic linux-headers-generic # RHEL / Rocky / AlmaLinux $ sudo dnf check-update kernel $ sudo dnf update kernel kernel-core # Amazon Linux 2023 $ sudo dnf update kernel
中長期: カーネル更新運用とHWE/GA選択
Copy Fail から得られる教訓は、緩和策ではありません。「カーネル更新を業務影響を理由に何ヶ月も先延ばしにしている運用」が、ここで一気に弱点になっている、という事実のほうです。私自身、SE時代に「LTSだから5年放置していい」と勘違いしていたサーバーがありました。LTSは「メジャーバージョンを5年据え置ける」のであって、「マイナーバージョンを更新しなくていい」では断じてありません。中長期に効く運用は、次の3点だと思います。
HWEカーネルとGAカーネルの選択を意識する
Ubuntu LTS には、GAカーネル(リリース時のカーネルを5年据え置き)と HWEカーネル(半年ごとに新しい upstream カーネルに乗り換え)があります。HWEは新しいセキュリティ修正を取り込みやすい反面、ロールバック互換に気を遣う。GAは安定だが、今回のように「上流ではすでに直っているのに手元だけ古い」事故が起きやすい。本番機ごとに HWE / GA を意図して選び分けることが必要です。両方を「なんとなくデフォルト」のままにしている運用が、いま一番危ない。apt-mark hold を見直す
「カーネルだけ apt-mark hold で更新止めている」運用、心当たりはないでしょうか。私もありました。NIC ドライバが壊れたトラウマで linux-image-* を hold していた時期があります。今回のような広範な脆弱性が出ると、その hold が負債として一気に顕在化します。hold を解除して新カーネルを当て、動作確認する一連を「3ヶ月に1回」運用ルールに格上げするのが現実的な落としどころです。無停止アップデート(live patching)の検討
Ubuntu Pro の Livepatch、RHEL の kpatch、SUSE の kGraft。それぞれ「再起動なしでカーネルパッチを当てる」仕組みです。再起動枠が四半期に1回しか取れない本番機では、ライセンス費用に対して十分にコストが見合います。受講生から「Livepatch は課金して元が取れますか」と聞かれたら、最近は「今回みたいな緊急対応が年1本でもあれば十分元が取れます」と答えています。Copy Fail は「2017年から潜んでいたバグがAI監査ツールで掘り起こされた」事例です。同じ作りの「最適化・高速化・省メモリ化」は他のサブシステムにも眠っているはず。Xint Code のような AI監査ツール普及で、今後数年は同種の脆弱性が次々に出てくる前提で運用を組む。仮説ではなく、これは前提だと思います。
参考
・公式サイト Copy Fail: https://copy.fail/・Theori PoC リポジトリ: https://github.com/theori-io/copy-fail-CVE-2026-31431
・NVD CVE-2026-31431: https://nvd.nist.gov/vuln/detail/CVE-2026-31431
・Xint blog(Theori 解析): https://xint.io/blog/copy-fail-linux-distributions
・oss-security メーリングリスト: https://www.openwall.com/lists/oss-security/2026/04/29/23
・CERT-EU 勧告 2026-005: https://cert.europa.eu/publications/security-advisories/2026-005/
「カーネル更新を後回しにできない時代」の運用、自信を持てていますか?
uname -r、lsmod、modprobe.d、apt-mark、HWE/GA選択。記事で読むだけでなく、実機で繰り返し手を動かすことで初めて身につきます。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 前のページへ:パッチを当てても消えないバックドア|FIRESTARTERから学ぶLinuxサーバの永続化検知
- この記事の属するカテゴリ:Linux情報・技術・セキュリティへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます