Technology

Linux脆弱性「Copy Fail」の確認と応急処置：CVE-2026-31431で見ておきたいこと

CVE-2026-31431 はNVDに2026年4月22日に登録され、2026年4月29日に「Copy Fail」として公開開示されました。

ざっくり言うと、条件を満たすLinux環境で、低権限のローカルユーザーがroot権限へ昇格できる可能性がある問題です。ネットワーク越しに直接侵入されるタイプの脆弱性ではありませんが、共有サーバー、CI/CDランナー、コンテナホスト、Webアプリ侵害後の横展開では無視しにくいリスクになります。

この記事では、攻撃手順やPoCには踏み込まず、一般的なLinuxユーザーや開発者が手元の環境で確認できること、修正済みカーネルが入るまでの応急処置、公式情報での確認ポイントに絞って整理します。

この記事で扱うこと

やることは大きく3つです。

  1. algif_aead が現在ロードされているか確認する
  2. 必要に応じて algif_aead の自動ロードを止める
  3. カーネル更新を適用し、各ディストリビューションの公式情報で状態を確認する

ここで紹介する algif_aead の無効化は、あくまで応急処置です。根本対応は、利用しているディストリビューションが配布する修正済みカーネルへ更新することです。

また、修正済みかどうかは単純なカーネル番号だけでは判断しない方が安全です。ディストリビューションによっては、メインラインのバージョン番号とは別に修正だけをバックポートするため、最終的にはUbuntu、Debian、Red Hatなど各公式トラッカーでCVE-2026-31431のステータスを確認してください。

Copy Failとは

Copy Fail（CVE-2026-31431）は、Linuxカーネルのユーザー空間向け暗号APIまわりにあるローカル権限昇格脆弱性です。

公開情報を整理すると、主なポイントは次の通りです。

  • CVE：CVE-2026-31431
  • 種別：ローカル権限昇格（LPE）
  • CVSS 3.1：7.8（HIGH）
  • NVD登録日：2026年4月22日
  • Copy Failとしての公開開示日：2026年4月29日
  • 関連モジュール：algif_aead
  • 影響範囲：2017年以降に導入された該当コードを含む多くのカーネル
  • 修正済み上流系リリースの例として挙げられているもの：7.0、6.19.12、6.18.22など

ただし、LTS/stable系や各ディストリビューションのバックポート状況は別です。古いLTSやベンダー独自カーネルでは例外もあり得るため、最終的には各公式トラッカーで確認してください。

重要なのは、これは「外部からいきなりrootを取られる」問題ではなく、すでに何らかの方法でローカル実行権限を持っている攻撃者がrootへ昇格する可能性がある問題だという点です。

個人PCだけを見ると少し遠く感じるかもしれません。一方で、Webアプリの実行ユーザー、CIジョブ、コンテナ内のユーザー、共有サーバーの一般ユーザーがrootへ上がれる可能性を考えると、運用環境では早めに確認したい脆弱性です。

応急処置の考え方

この記事で紹介する応急処置は、algif_aead というカーネルモジュールを読み込ませないようにするものです。

攻撃経路に関係するモジュールをロードできない状態にしておくことで、修正済みカーネルが入るまでのリスクを下げます。Ubuntuでは、kmod パッケージの更新によって同様の緩和策が配布されています。

ただし、これはあくまで緩和策です。algif_aead を止めることは脆弱なコードパスを避けるための一時対応であり、カーネル本体の脆弱性を修正するものではありません。最終的には、各ディストリビューションが配布する修正済みカーネルへ更新してください。

停止しても大丈夫か

多くの一般的なデスクトップ・サーバー利用では、algif_aead を止めても影響は出にくいと考えられます。SSH、HTTPS、LUKS、GPG、通常のOpenSSL利用などが、必ずこのモジュールに依存しているわけではありません。

一方で、暗号オフロード利用や、アプリケーション側がユーザー空間の暗号処理へ適切にフォールバックできるかによっては影響する可能性があります。

そのため、次のような環境では事前確認をおすすめします。

  • OpenSSLの afalg エンジンを明示的に使っている
  • 組み込み機器などでハードウェア暗号オフロードを AF_ALG 経由で使っている
  • AF_ALG を直接利用する独自アプリケーションがある

不安な場合は、次のコマンドで関連するソケットやプロセスが見えるか確認します。

sudo lsof 2>/dev/null | grep -i AF_ALG
ss -xa | grep -i alg

何も出なければ、少なくとも現在動いているプロセスが明示的に使っている可能性は低いです。ただし、これだけで将来起動するアプリケーションの影響まで保証できるわけではないため、特殊な暗号オフロードを使っている環境では運用担当者やベンダー情報も確認してください。

ステップ1：現在の状態を確認する

まず、algif_aead が現在ロードされているか確認します。

grep -qE '^algif_aead ' /proc/modules && echo "ロード中：要対応" || echo "未ロード"

未ロード と出た場合、今この瞬間はモジュールが動いていません。

ただし、ここで終わりではありません。algif_aead は必要になったタイミングで自動ロードされる可能性があります。つまり「今ロードされていない」だけでは、攻撃経路を継続的に塞いだことにはなりません。

ステップ2：自動ロードを止める

修正済みカーネルへ更新するまでの応急処置として、algif_aead をロードできないようにします。

# 起動時・要求時にロードされないよう設定
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/manual-disable-algif_aead.conf

# すでにロード中ならアンロード
sudo rmmod algif_aead 2>/dev/null

# 結果確認
grep -qE '^algif_aead ' /proc/modules && echo "まだロード中" || echo "OK：ブロック完了"

OK：ブロック完了 と出れば、現在ロードされていない状態です。

Ubuntuを使っている場合は、Canonicalが kmod パッケージの更新で緩和策を配布しています。Ubuntuでは手動設定の前に、まずこちらを適用する方法もあります。

sudo apt update
sudo apt install --only-upgrade kmod

kmod 更新後は再起動してください。すぐに再起動できない場合は、公式手順を確認したうえで、ロード中の algif_aead をアンロードし、/proc/modules で状態を確認します。

kmod 更新はUbuntu向けの補足です。他のディストリビューションでは、それぞれの公式アドバイザリやパッケージ更新手順を確認してください。また、kmod の緩和策を入れた場合でも、カーネル更新の確認は続けて行います。

ステップ3：カーネルを更新する

応急処置だけで終わらせず、カーネルを最新化します。

Ubuntu / Debian / Linux Mint系なら、通常は次の流れです。

sudo apt update
sudo apt upgrade
sudo reboot

Fedora / RHEL / AlmaLinux系なら、次のような流れです。

sudo dnf upgrade --refresh
sudo reboot

再起動後は、各ディストリビューションの公式ページでCVE-2026-31431のステータスを確認してください。

Ubuntuについても、「このカーネル番号なら必ず修正済み」とこの記事内では断定しません。配布時期、リリース、フレーバー、バックポート状況で見え方が変わる可能性があるため、公式ページや apt changelog、ディストリビューションのセキュリティ通知で確認するのが確実です。

Ubuntuで「保留」が出た場合

Ubuntuで apt upgrade を実行したあとに、「保留：1個」のような表示が残ることがあります。

まずは中身を確認します。

apt list --upgradable

ここで iproute2 のようなCopy Failと直接関係ないパッケージが出ていて、deferred due to phasing のような文言がある場合は、Ubuntuのフェーズド配信による保留です。新しい更新を全員へ一斉配信せず、段階的に広げる仕組みなので、通常はしばらく待てば解消されます。

一方で、linux-image-* や linux-generic が保留されている場合は、カーネル更新が止まっている可能性があります。必要に応じて次を検討します。

apt -s full-upgrade
sudo apt full-upgrade
sudo reboot

apt -s full-upgrade はシミュレーションです。実際に削除・更新されるパッケージを確認してから sudo apt full-upgrade に進みます。サーバーでは依存関係の変更や再起動の影響があるため、メンテナンス時間を確保してから実行してください。

古いカーネルが残っている場合

過去のカーネルが大量に残っていると、/boot の容量を圧迫することがあります。

確認するには次を実行します。

dpkg -l 'linux-image*' | grep '^ii'

不要な古いカーネルは、通常次のコマンドで整理できます。

sudo apt autoremove --purge --dry-run
sudo apt autoremove --purge

まず --dry-run で削除対象を確認してから実行します。最新カーネルと、念のため1つ前のカーネルを残す運用にしておくと、問題が起きたときに戻しやすくなります。

元に戻したい場合

この記事の手順で手動作成した algif_aead のブロックを解除したい場合は、その設定ファイルだけを削除して再起動します。

sudo rm /etc/modprobe.d/manual-disable-algif_aead.conf
sudo reboot

ただし、解除するのは修正済みカーネルへ更新したあとにしてください。更新前に戻すと、応急処置を外した状態になります。

Ubuntuの kmod 更新で入った緩和策を解除したい場合は、この手動ファイル削除とは別の話になります。互換性問題などで解除が必要になった場合は、Canonicalの公式案内を確認してください。

まとめ

Copy Fail（CVE-2026-31431）は、Linuxカーネルの algif_aead まわりにあるローカル権限昇格脆弱性です。リモートから直接侵入されるものではありませんが、すでに低権限でコードを実行できる状況ではrootへ昇格される可能性があります。

対応としては、次の3つを押さえておくとよさそうです。

  • algif_aead がロードされているか確認する
  • 修正済みカーネルが入るまで、自動ロードを止める
  • カーネル更新を適用し、公式トラッカーで状態を確認する

特に共有サーバー、CI/CDランナー、コンテナホスト、Kubernetesノードでは優先して確認したいところです。個人PCでも、普段から開発用コンテナやローカルCIを使っている場合は、ディストリビューションの更新状況を一度見ておくと安心です。

参考リンク

水上凌佑

　水上凌佑

スキル：Java/C/C++/Node.js/PHP/Python/TypeScript/PostgreSQL/MySQL/SpringBoot/Rust/Linux(Omarchy)/AWS/Gemini/Antigravity/Security/Software Design

コメント

この記事へのコメントはありません。

関連記事
Technology

『これJavaならどう書くの？』から始めるRust入門 ①：Cargo編
Technology

VSCode から Zed へ移行して、Codex CLI まで Rust 製で揃った話