CVE-2026-31431 は、公開上 Copy Fail と呼ばれており、AF_ALG を介してカーネルユーザースペース暗号APIのAEADインターフェースを実装する algif_aead モジュールに関連するLinuxカーネルのローカル権限昇格の脆弱性です。

実際には、この問題により、低権限のローカルユーザーがこのサブシステムのメモリ処理経路における論理的な欠陥を悪用し、システム全体の整合性を侵害するまで影響を拡大できる可能性があります。kernel.org によって公開され、NVDに反映されているスコアは CVSS 7.8 で、ベクターは AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H であり、攻撃にはローカルでの実行が必要ですが、機密性、整合性、可用性に高い影響を与えることを意味します。

導入時期と開示時期

• 悪用可能な根本原因は、algif_aead にインプレース最適化が追加された 2017年 にカーネルに導入されました。
• CVEは 2026年4月22日 にNVDで公開されました。
• Copy Fail という名前と公開された概念実証を伴う、この問題のより広範な公開開示は 2026年4月29日 に行われました。
• 主要なアップストリーム修正は、エンドユーザーへの広範な開示前の 2026年4月1日 にコミットされました。

悪用される内容

公開された技術アドバイザリによると、この欠陥は以下の組み合わせに依存しています:

• カーネル AF_ALG インターフェース
• algif_aead モジュール
• 2017年に導入されたインプレース操作最適化
• このインターフェースと splice() の連鎖

実際の結果として、ローカルプロセスが読み取り可能なファイルのページキャッシュバックアップページに対して、小さな制御された書き込みを実行できるようになります。好条件では、限定的なローカルでの足掛かりを root 権限昇格に変えるのに十分です。

会社への影響

実際のリスクは、単に「脆弱なLinuxカーネルを実行している」ことではなく、低信頼のローカルコードがこのカーネル経路に到達できるようにすることです。エンタープライズ環境では、これは通常、以下の場所での曝露が高くなることを意味します:

• マルチユーザーサーバー
• ジャンプホストおよび要塞ホスト
• CI/CDランナー
• 信頼できないコードを実行するコンテナ化されたワークロード
• Kubernetesクラスター
• 自動化、エージェント、プラグイン、またはサードパーティのジョブをホストするVM

攻撃者がすでに何らかの形のローカル実行権限を持っている場合、root 権限がなくても、このCVEはホスト侵害への次のステップになり得ます。実際には、これにより以下のリスクが拡大します:

• サーバーの完全な乗っ取り
• ローカルバイナリまたはアーティファクトの改ざん
• 認証情報、トークン、常駐シークレットの窃取
• 他の資産への横移動
• パイプラインおよびビルドチェーンの妨害

algif_aead モジュールの用途

algif_aead はカーネルユーザースペース暗号インターフェース（AF_ALG）の一部です。これにより、アプリケーションはソケットを介してカーネルの暗号プリミティブ、特に AEAD 操作（認証付き暗号化）を使用できます。

このモジュールは、通常、ほとんどの標準的なサーバーワークロードには必須ではありません。CERT-EUが公開した緩和ガイダンスによると、一時的な緩和策として algif_aead を無効にすることは:

• dm-crypt または LUKS には影響しないはずです
• kTLS には影響しないはずです
• IPsec/XFRM には影響しないはずです
• 標準的な使用における OpenSSL、GnuTLS、NSS、または SSH には影響しないはずです

一方で、無効にすると以下に影響を与える可能性があります:

• afalg エンジンを使用するように明示的に設定されたアプリケーション
• AF_ALG ソケットを直接開くソフトウェア
• カーネル暗号APIを介して aead、skcipher、または hash を使用するカスタム統合

言い換えれば、ほとんどの企業ホストでは、モジュールをブロックしても影響は低い傾向があります。アプライアンス、カスタム暗号スタック、または高度に最適化されたソフトウェア経路では、ロールアウト前に影響を検証する必要があります。

モジュール無効化の運用上の影響

モジュールをブロックすると曝露は直ちに軽減されますが、トレードオフが伴います:

• AF_ALG に依存するアプリケーションは起動に失敗するか、カーネルバックアップの暗号アクセラレーションを失う可能性があります
• カスタムワークロードはブート時ではなく、実行時にのみ失敗する可能性があります
• モジュールがすでにロードされている場合、緩和策はアンロードまたは再起動が成功した後にのみ完了します

本番環境では、制御されたメンテナンスウィンドウで緩和策を適用し、その後クリティカルなアプリケーションを検証する方が安全なアプローチです。

推奨される恒久的な修正

モジュールのブラックリスト登録は一時的な緩和策にすぎません。恒久的な修正は以下のとおりです:

1. ディストリビューションベンダーが提供するパッチ適用済みカーネルをインストールする
2. 新しいカーネルが実際にロードされるようにホストを再起動する
3. ホストが影響を受けると報告されなくなったことを検証する
4. その後にのみ、モジュールのブラックリストを残すべきかどうかを決定する

追加の推奨対策:

• ローカルユーザー、コンテナ、または信頼できないコード実行があるホストのパッチ適用を優先する
• 該当する場合は、コンテナおよびパイプラインで seccomp を使用して AF_ALG ソケットの作成を制限する
• afalg またはカーネル暗号APIが明示的に使用されている場所を確認する
• カーネルバージョンと保留中の再起動のインベントリを維持する
• CI/CDランナーとKubernetesノードを高優先度として扱う

スクリプトがチェックする内容

スクリプトは以下を検査します:

• ホストのホスト名
• 実行中のカーネルバージョン
• /etc/os-release を介したオペレーティングシステム
• algif_aead モジュールの存在
• モジュールが現在ロードされているかどうか
• モジュールが modprobe ルールによってブロックされているかどうか
• ホストが再起動を必要とするかどうか（/var/run/reboot-required）
• 利用可能な場合、pro fix CVE-2026-31431 --dry-run を介してUbuntu Proによって報告されたステータス

これに基づいて、以下の分類のいずれかを返します:

• PATCHED_OR_NOT_AFFECTED
• LIKELY_NOT_VULNERABLE
• MITIGATED
• VULNERABLE_MODULE_LOADED
• POTENTIALLY_VULNERABLE
• UNKNOWN

分類ロジック

要約すると:

• Ubuntuツールがホストが影響を受けていないか、すでに修正されていることを示している場合、ステータスは PATCHED_OR_NOT_AFFECTED になります。
• algif_aead モジュールが現在のカーネルに存在しない場合、ステータスは LIKELY_NOT_VULNERABLE になる傾向があります。
• モジュールが存在するがブロックされておりロードされていない場合、ステータスは MITIGATED になります。
• Ubuntuがホストが影響を受けていることを示し、モジュールがロードされている場合、ステータスは VULNERABLE_MODULE_LOADED になります。
• モジュールが存在しロード可能であるが、パッチ状態を確認できない場合、ステータスは POTENTIALLY_VULNERABLE になります。

要件

• Bash
• modinfo
• modprobe
• lsmod
• awk
• grep
• hostname
• uname
• --update 用の apt-get
• 非rootユーザーとして実行する場合の sudo
• Ubuntuでの分析を強化するためのオプションの pro

使用方法

スクリプトファイルが check_cve_2026_31431.sh という名前の場合:

デフォルトのチェック

出力例:

JSON出力

例:

この出力は、自動化、資産インベントリ、およびコンプライアンスパイプラインに役立ちます。

緩和策

--mitigate モードは以下のファイルを作成します:

以下の内容で:

その後、スクリプトは以下のコマンドでメモリからモジュールを削除しようとします:

使用方法:

ユーザーが root でない場合、スクリプトは sudo を使用しようとします。

更新

--update モードは以下を実行します:

使用方法:

このモードは、DebianおよびUbuntuベースのシステムでカーネル関連パッケージのアップグレードを試みます。他の環境では、この手順は適用されない場合があります。

ヘルプ

出力:

重要な制限事項

• スクリプトはヒューリスティックを使用します。悪用を証明するものではなく、曝露と緩和状態を推定するものです。
• ubuntu_affected および fix_available フィールドは、pro コマンドの存在に依存します。
• --update 手順はUbuntuおよびDebian向けのパッケージパターンを使用しており、すべてのカスタムカーネルをカバーできない場合があります。
• 一部のディストリビューションでは、モジュールがスクリプトの想定とは異なる動作で存在する場合があります。
• モジュールのブロックは、一貫した状態を保証するために一部の環境では再起動が必要になる場合があります。

推奨ワークフロー

1. --check を実行してホストを評価します。
2. モジュールが利用可能でパッチが適用されていない場合は、--mitigate を実行します。
3. --update を実行するか、公式ベンダーアップデートを適用します。
4. 必要な場合はホストを再起動します。
5. --check --json を実行して最終状態を検証し、証拠を保持します。

注記

公開の明確さのために、スクリプトは理想的には以下のような説明的な名前を使用する必要があります:

クレジット

SEC17 の功績により資料が整理され公開されています。

公式ウェブサイト:

• https://sec17.com