Tech BlogAWSツール & 技術ブログ
メニュー

カテゴリ

AWS & AI ツール

タグ

Claude Code13AI13AWS9セキュリティ7効率化5開発ツール5Claude4プラグイン3S33CloudFront3API2チートシート2すべて見る →

Linuxカーネル脆弱性「Copy Fail」（CVE-2026-31431）のまとめ：AWS EC2・ECS環境での緩和策

セキュリティLinuxカーネルCVEAWSEC2ECSAmazon Linux

何が起きたのか

2026年4月22日、Linuxカーネルの暗号化API（algif_aead）に存在する論理欠陥が CVE-2026-31431 として公表されました。研究者は専用サイト copy.fail でこの脆弱性を「Copy Fail」と命名し、PoCコードと技術解説を同時公開しています。

特徴を一言でまとめると、次の通りです。

  • 一般ユーザ権限で 任意のsetuidバイナリを書き換え可能 な、ローカル権限昇格の脆弱性
  • PoCはわずか 732バイトのPythonスクリプト、信頼性は「100%」と主張されている
  • レース条件もカーネルオフセットも不要な「直線的な論理フロー」の欠陥
  • 欠陥は約9年前から潜伏しており、2017年以降のほぼすべてのLinuxディストリビューションが影響を受ける

そして本題、AWSのAmazon Linux 2 / Amazon Linux 2023も例外ではありません。今日（2026年4月30日）時点で、AWSの脆弱性データベース ALAS ではすべてのカーネルパッケージが「Pending Fix」の状態で、修正版はまだ提供されていません。

EC2上で動くワークロードはもちろん、内部的にEC2を使うECS（EC2起動タイプ）やEKSのワーカーノードも影響を受けるため、AWS利用者であれば一度は把握しておきたい脆弱性です。

CVE-2026-31431 の基本情報

ALASに掲載されている基本情報は以下の通りです。

項目 内容
CVE ID CVE-2026-31431
通称 Copy Fail
公開日 2026-04-22
深刻度 Important
CVSSv3 基本スコア 7.8
CVSSv3 ベクトル AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
影響を受けるサブシステム Linuxカーネルの crypto: algif_aead
修正コミット a664bf3d603d（"Revert to operating out-of-place"）

CVSSベクトルを読み解くと、攻撃には ローカルアクセス（AV:L）が必要で、低い権限（PR:L）があれば成立し、機密性・完全性・可用性すべてに高い影響（C:H/I:H/A:H）を与えるカーネル脆弱性であることがわかります。

リモートから単独で悪用できる脆弱性ではないものの、初期侵入後の権限昇格に使われる典型的なパターンであり、マルチテナント環境やSSHが許可されているEC2では特に危険です。

攻撃の仕組み（ざっくり解説）

公式の解説によると、根本原因は次のように説明されています。

A single logic bug in authencesn is chained through AF_ALG and splice() to write 4 bytes into the page cache.

つまり、

  1. Linuxカーネルの暗号化アルゴリズム authencesn における1つの論理バグを、
  2. ユーザ空間からカーネルの暗号機能を扱う AF_ALG ソケットと、
  3. パイプ間でデータをコピーする splice() システムコールを連結し、
  4. 結果としてページキャッシュに 任意の4バイトを書き込む

という流れです。この4バイト書き込みを足がかりに、攻撃者はsetuidバイナリの命令列を改変し、結果として ルート権限でのコード実行 を達成します。

「たかが4バイト」と侮れないのが厄介なところで、ELFバイナリの命令列を狙い撃ちすればそれだけで権限昇格が成立してしまいます。

なお、再起動すれば書き換えられたページキャッシュ自体はリセットされますが、攻撃中にroot権限で永続化処理を仕込まれていれば再起動では取り戻せません。検知と再構築の判断が必要になります。

AWSでの影響範囲

Amazon Linux のステータス（2026-04-30 時点）

ALASによると、影響を受けるリポジトリは以下の通りです。すべて Pending Fix で、修正版はまだ未提供です。

  • Amazon Linux 2: Core, Kernel-5.4 Extra, Kernel-5.10 Extra, Kernel-5.15 Extra
  • Amazon Linux 2023: 標準カーネル, kernel6.12, kernel6.18

影響を受けるAWSサービス

サービス 影響 備考
EC2（AL2 / AL2023） あり カーネル更新が必要
ECS（EC2起動タイプ） あり コンテナホスト＝EC2なので同じ脆弱性を持つ
ECS（Fargate起動タイプ） AWS側で対応 利用者側のパッチ作業は不要だが、AWSの対応完了を待つ
EKS（マネージドノード） あり ノードのAMI更新が必要
Lambda AWS側で対応 ランタイムOSはAWSが管理
RDS / Aurora AWS側で対応 マネージドサービスのためAWSが対処

自分でOSを管理しているEC2系のサービスは、自分でパッチを当てる必要がある という点が今回のポイントです。Fargate / Lambda / RDS のようなマネージドサービスは基本的にAWS側で順次対応されますが、利用者がOS管理権限を持つEC2 / ECS（EC2）/ EKSノードについては、ユーザ側でアクションが必要です。

コンテナ環境での注意点

「ECSやEKSのコンテナはホストから隔離されているから大丈夫では？」と思いがちですが、カーネルはホストと共有 です。コンテナ内の低権限ユーザがCopy Failを発動できれば、カーネル空間で4バイト書き込みが成立し、結果としてホスト側のsetuidバイナリ改変につながります。

特に以下のような構成は注意が必要です。

  • マルチテナントで他社のコンテナと同居するEC2ノード
  • コンテナ内でビルド処理を回すCI/CDワーカー（信頼できないコードを動かす可能性がある）
  • エンドユーザがコードを実行できるサンドボックス環境

このブログ運用での自分の対応

このブログ自体は Next.js + S3 + CloudFront（静的エクスポート構成）で運用しているため、EC2は使っておらず本脆弱性の直接影響はありません。とはいえ、AWSアカウント内には別件で動かしているEC2やECS環境があるため、確認手順を整理しました。

Step 1: 動いているEC2をリストアップ

# 起動中のEC2を一覧（AL2 / AL2023 を識別）
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].[InstanceId,Platform,Tags[?Key==`Name`].Value|[0],ImageId]' \
  --output table

Step 2: カーネルバージョンの確認

SSM Run Commandを使えばSSHしなくても一括で確認できます。

aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --targets "Key=tag:Environment,Values=production" \
  --parameters 'commands=["uname -r","cat /etc/os-release | grep PRETTY_NAME"]'

Step 3: 緩和策の適用状態を確認

後述の algif_aead 無効化が入っているか確認します。

lsmod | grep algif
ls /etc/modprobe.d/ | grep algif

普段ECRイメージのビルドに使っているCodeBuildや、開発用に立てているEC2踏み台もリストに上がってきたので、この機にパッチ運用フローを見直すきっかけになりました。

パッチ提供前にできる緩和策

AWSからの修正版カーネルが出るまでの間、すぐに実施できる緩和策を3つ紹介します。

緩和策 1: algif_aead モジュールの無効化（推奨）

研究者自身が推奨している最もシンプルな方法です。algif_aead カーネルモジュールのロードを禁止することで、攻撃のトリガーとなる AF_ALG 経由のAEAD暗号化操作を遮断します。

# 全EC2に適用（SSM Run Commandの例）
aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --targets "Key=tag:Environment,Values=production" \
  --parameters 'commands=[
    "echo \"install algif_aead /bin/false\" | sudo tee /etc/modprobe.d/disable-algif.conf",
    "sudo rmmod algif_aead 2>/dev/null || true",
    "lsmod | grep algif_aead || echo OK: algif_aead is unloaded"
  ]'

副作用について

公式解説では「ほとんどのシステムで機能低下なし」とされていますが、AF_ALG を明示的に使うアプリケーションは影響を受けます。具体的には、

  • カーネルcryptoをユーザ空間から呼び出すVPN実装の一部
  • cryptsetup の特定オプションを使ったディスク暗号化
  • 一部のIPSec実装

を使っている場合は、無効化前に動作確認が必要です。一般的なWebアプリケーションサーバやアプリケーションホストであれば、まず影響は出ないはずです。

緩和策 2: seccompで AF_ALG ソケット作成をブロック

信頼できないコードを実行するコンテナ環境では、seccompプロファイルで AF_ALG ソケットの作成自体をブロックする方法が有効です。

ECSタスク定義であれば linuxParameters.systemControls ではなくDockerのセキュリティオプション経由で渡すか、カスタムseccompプロファイルを s3 に置いて読み込ませる構成になります。EKSであればPodSecurityPolicyの後継である Pod Security Standards の restricted プロファイルを基本適用としつつ、カスタムseccompを当てます。

サンプルseccompプロファイル（AF_ALGをブロック）：

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [
        { "index": 0, "value": 38, "op": "SCMP_CMP_EQ" }
      ]
    }
  ]
}

38 は AF_ALG のドメイン番号です。コンテナから socket(AF_ALG, ...) が呼ばれた瞬間にエラーで弾けます。

緩和策 3: 不要な低権限アカウントの棚卸し

Copy Failはローカル権限昇格の脆弱性のため、そもそも一般ユーザがログインできない環境では悪用されません。これを機に以下を見直すと安全度が一段上がります。

  • 退職者・異動者のSSHキーが残っていないか
  • IAMロール経由のSSM Session Managerに統一できないか（SSHキー管理を廃止）
  • 利用していない開発用EC2は停止・削除

パッチ提供後の対応

AWSから修正版カーネルが提供されたら、以下の流れで適用します。Pending Fix状態のうちは、ALAS RSSやyum check-updateを定期チェックする運用にしておくのがおすすめです。

Amazon Linux 2 / 2023 共通

# パッケージ更新（カーネル含む）
sudo dnf update -y kernel    # AL2023
sudo yum update -y kernel    # AL2

# 再起動でカーネル切り替え
sudo reboot

Auto Scaling Group / Launch Template での運用

EC2を1台ずつメンテするのは現実的ではないため、本番環境ではゴールデンAMIを再ビルドしてAuto Scaling Groupに反映する運用を取ります。

# 1. AMI再ビルド（EC2 Image Builder利用例）
aws imagebuilder start-image-pipeline-execution \
  --image-pipeline-arn arn:aws:imagebuilder:...

# 2. Launch Templateの新バージョン作成

# 3. ASGをローリング更新（Instance Refresh）
aws autoscaling start-instance-refresh \
  --auto-scaling-group-name my-asg \
  --preferences '{"MinHealthyPercentage": 90, "InstanceWarmup": 300}'

ECS（EC2起動タイプ）の場合は ECS最適化AMI が更新されるのを待ち、Capacity Provider経由でローリング更新する流れになります。EKSであればマネージドノードグループの「Update node group version」で対応できます。

まとめ

  • CVE-2026-31431（Copy Fail）はLinuxカーネルの暗号化APIにある論理欠陥で、ローカルの低権限ユーザがroot権限を奪取できる脆弱性
  • 2017年以降のほぼ全Linuxに影響、Amazon Linux 2 / 2023 / ECS（EC2起動タイプ）も対象
  • 2026年4月30日時点ではAWS側はPending Fix、修正版カーネルは未提供
  • パッチ提供前は algif_aead モジュールの無効化が最も簡単で効果的な緩和策
  • 信頼できないコードを動かすコンテナ環境ではseccompで AF_ALG ソケット作成をブロックする
  • パッチ提供後はAMI再ビルド + Auto Scaling Group のInstance Refreshで全台適用する運用にしておく

ローカル権限昇格脆弱性は「外から直接来ない」分、対応の優先度を下げてしまいがちですが、SSRFやアプリケーションの脆弱性経由で踏み台を取られた後の 横展開・永続化のラスト1マイル で使われる代表格です。EC2を運用しているなら、緩和策の適用とパッチ運用フローの整備をこの機会にやっておきたいところです。

進捗は ALASのCVE-2026-31431ページ を定期的にチェックし、修正版がリリースされ次第すぐに適用できるよう準備しておきましょう。

関連記事

← 記事一覧に戻る