セキュリティニュース

2026/4/30

Linuxカーネル「Copy Fail」脆弱性、主要ディストリビューションに広範な影響　732バイトPoCでroot権限昇格

セキュリティ研究会社Theori（テオリ）は2026年4月29日、Linuxカーネルの暗号化サブシステムに存在する深刻な権限昇格脆弱性「Copy Fail」（CVE-2026-31431）を公表した。この脆弱性により、一般ユーザーは732バイトの短いPythonスクリプトを実行するだけで、テストされた主要なLinuxディストリビューション（Ubuntu、RHEL、Amazon Linux、SUSE）で管理者権限への昇格が可能となる。問題のあるコードは2017年から存在し、約9年間にわたって発見されずにいた。

【3行要約】

何が起きた：Linuxカーネルの暗号化機能に論理的欠陥があり、ページキャッシュへの4バイト書き込みが可能

影響：2017年以降の主要Linuxディストリビューション全てで一般ユーザーからroot権限への昇格が可能

対応：カーネルパッチの適用済み、暫定措置としてalgif_aeadモジュールの無効化が有効

わかっていること・わかっていないこと

見出し

1 わかっていること・わかっていないこと
2 脆弱性の発見経緯とAI支援
3 技術的な仕組み
4 攻撃の特徴と影響
5 修正と対応状況
- 5.1 対処方法
6 企業環境への影響
7 タイムライン
8 情報源

✓ わかっていること

脆弱性は2017年にカーネルコミット72548b093ee3で導入された
authencesnアルゴリズムの仕様上の問題とAF_ALG、splice()の組み合わせで発現
732バイトのPythonスクリプトで4つのディストリビューション（Ubuntu、RHEL、Amazon Linux、SUSE）でのroot権限取得を確認
コンテナ環境でもホストシステムへの脱出が可能
修正パッチ（a664bf3d603d）は2026年4月1日にメインラインカーネルにマージ済み
CVSS 3.1スコア7.8（高深刻度）の評価（kernel.org CNA）

? わかっていないこと

実環境での悪用事例の有無
過去9年間の潜在的な攻撃件数
他の類似した暗号化モジュールでの同様の問題の存在
企業環境での実際の被害状況

脆弱性の発見経緯とAI支援

この脆弱性の発見には人工知能が重要な役割を果たした。Theori社の研究者Taeyang Lee氏がLinuxの暗号化サブシステムとページキャッシュの相互作用に注目し、同社のAI支援セキュリティ監査ツール「Xint Code」を使用してカーネル全体をスキャンした。わずか1時間程度の解析で、10年近く潜んでいたこの論理的欠陥が特定されたという。

同スキャンでは他にも高深刻度の脆弱性が複数発見されており、現在も協調開示の手続きが進められている。

技術的な仕組み

Copy Failは、Linuxカーネルの3つのコンポーネントが組み合わさることで発生する。まず、AF_ALGは一般ユーザーがカーネルの暗号化機能にアクセスできる仕組みを提供している。次に、splice()システムコールはファイルデータをコピーせずにページキャッシュを直接参照してデータ転送を行う。最後に、authencesnアルゴリズムは暗号化処理中に出力バッファを作業領域として使用する設計になっている。

問題は、2017年の最適化によってAF_ALGが同じスキャッターリストを入力と出力の両方に使用するようになったことだ。この結果、ページキャッシュのページが書き込み可能な領域として扱われ、authencesnが処理中に4バイトの書き込みを行う際、ファイルのメモリ上コピーが改ざんされる。

攻撃の特徴と影響

Copy Failが過去の権限昇格脆弱性と大きく異なる点は、その確実性と隠密性にある。「Dirty COW」などの従来の脆弱性がレースコンディションに依存し失敗やクラッシュのリスクがあったのに対し、Copy Failは論理的な欠陥であるため、研究者はテストした主要ディストリビューション上で同一PoCによる安定したroot権限取得を確認したとしている。

また、攻撃による変更はディスク上のファイルではなくメモリ上のページキャッシュにのみ影響するため、一般的なファイル整合性チェックツールでは検出が困難だ。しかし、プログラム実行時にはメモリ上の改ざんされたデータが参照されるため、攻撃者はsetuidバイナリに不正なコードを注入して実行できる。

特に深刻なのは、コンテナ環境への影響である。ページキャッシュはホストOS全体で共有されているため、一つのコンテナ内で実行された攻撃が、ホストシステム全体や他のコンテナのセキュリティを破壊する「コンテナ脱出」の手段となる。

修正と対応状況

Linuxカーネル開発チームは問題の本質を受けて、根本的な修正を実施した。修正パッチ（コミットa664bf3d603d）は2017年の最適化を完全に撤回し、AF_ALGのAEAD処理を再びout-of-place方式に戻している。これにより、ページキャッシュのページが書き込み可能な領域に配置されることがなくなった。

2026年4月30日時点で、各ディストリビューションで対応が進んでいるが、系列・カーネルパッケージごとに未修正が残る状況である。例えばDebian trackerではbullseye/bookworm/trixieがvulnerable、SUSEも多くの製品をAffected状態としている。利用中の配布元アドバイザリで修正済みバージョンを確認する必要がある。Red Hat社は当初修正の延期を表明していたが、後に方針を変更し迅速な対応を行うことを発表した。

対処方法

1. カーネル更新による根本的対策

# Ubuntu/Debian系
sudo apt update &amp;&amp; sudo apt upgrade linux-*
sudo reboot

# RHEL/CentOS/Fedora系
sudo dnf update kernel
sudo reboot

# SUSE系
sudo zypper update kernel-*
sudo reboot

# Ubuntu/Debian系

sudo apt update && sudo apt upgrade linux-*

sudo reboot

# RHEL/CentOS/Fedora系

sudo dnf update kernel

sudo reboot

# SUSE系

sudo zypper update kernel-*

sudo reboot

2. 暫定措置：algif_aeadモジュールの無効化

即座のアップデートが困難な場合、以下のコマンドで問題のあるモジュールを無効化できる。

# モジュールの現在の状態確認
lsmod | grep algif_aead

# モジュールを永続的に無効化（以下のいずれかを実行）
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf
# または、rootで直接実行する場合:
# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf

# 現在ロードされているモジュールを削除
sudo rmmod algif_aead 2>/dev/null || true

# 設定確認
cat /etc/modprobe.d/disable-algif-aead.conf

# モジュールの現在の状態確認

lsmod | grep algif_aead

# モジュールを永続的に無効化（以下のいずれかを実行）

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf

# または、rootで直接実行する場合:

# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf

# 現在ロードされているモジュールを削除

sudo rmmod algif_aead 2>/dev/null || true

# 設定確認

cat /etc/modprobe.d/disable-algif-aead.conf

このモジュール無効化は一般的なシステムではほとんど影響せず、LUKS、SSH、OpenSSL、IPsecなどの主要な暗号化機能には影響を与えない。ただし、CONFIG_CRYPTO_USER_API_AEAD=yのように組み込み構成されたカーネルでは、単純なrmmod/modprobe blacklistが効かない場合がある。そのため、モジュールとして構成されていないカーネルではこの回避策が効かない場合があり、コンテナ・CI環境ではAF_ALGソケット作成をseccomp等で制限する対策も検討する。

3. コンテナ・マルチテナント環境での追加対策

マルチテナント環境やCI/CD環境では、seccompプロファイルを使用してAF_ALGソケットの作成を制限することを強く推奨する。これは組み込みカーネルでのモジュール無効化が困難な場合の有効な対策でもある：

# Dockerでの例：AF_ALGソケット作成を禁止するseccompプロファイル
{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ"
        }
      ]
    }
  ]
}

# Dockerでの例：AF_ALGソケット作成を禁止するseccompプロファイル

{

"defaultAction": "SCMP_ACT_ALLOW",

"syscalls": [

{

"names": ["socket"],

"action": "SCMP_ACT_ERRNO",

"args": [

{

"index": 0,

"value": 38,

"op": "SCMP_CMP_EQ"

}

]

}

]

}

注意：PoCコードは防御検証目的でのみ取り扱い、本番環境での実行は避ける。

企業環境への影響

この脆弱性は特に、複数のユーザーがシステムを共有する環境で深刻なリスクとなる。共有開発サーバー、CI/CDランナー、マルチテナントクラウド環境では、一般ユーザー権限を持つ攻撃者が管理者権限を取得し、システム全体を侵害できる可能性がある。

Kubernetesなどのコンテナ環境では、単一のPodで実行された攻撃がノード全体の侵害につながり、テナント間の境界を突破するリスクがある。

タイムライン

日付	出来事
2011年	authencesnアルゴリズムがカーネルに追加（コミットa5079d084f8b）
2015年	AF_ALGにAEADサポートが追加、authencesnが新AEAD方式に変換
2017年	algif_aeadにin-place最適化が追加（コミット72548b093ee3）、脆弱性発現
2026年3月23日	Theori社がLinuxカーネルセキュリティチームに脆弱性を報告
2026年3月24日	初期確認を受信
2026年4月1日	修正パッチがメインラインカーネルにコミット
2026年4月22日	CVE-2026-31431が割り当てられる
2026年4月29日	脆弱性の詳細が公開