CVE-2026-31431 — 「Copy Fail」

Linuxカーネルのcrypto algif_aead サブシステムにおけるローカル権限昇格。

概要

CVE-2026-31431、通称「Copy Fail」は、Linuxカーネルの authencesn 暗号テンプレート（algif_aead）における論理バグです。これにより、権限のないローカルユーザーが任意の読み取り可能なファイルのページキャッシュに対して制御された4バイト書き込みを行うことができ、setuidバイナリを改変してrootを取得するために悪用される可能性があります。

• CVSS: 7.8（高）
• 影響を受けるバージョン: 2017年以降に出荷されたすべての主流Linuxカーネル
• エクスプロイト: 732バイトのPythonスクリプト — レースコンディションなし、カーネル固有のオフセットなし
• 修正: メインラインコミット a664bf3d603d

タイムライン

影響マトリックス

このエクスプロイトには、AF_ALG ソケット（すべてのseccompプロファイルでデフォルトで許可）とsetuidバイナリ（例: /usr/bin/su）の2つが必要です。主要な緩和策は allowPrivilegeEscalation: false です。これは、Linuxカーネルの no_new_privs フラグを prctl(PR_SET_NO_NEW_PRIVS, 1) で設定し、カーネルが execve() 時にsetuid/setgidビットを無視するようにします。エクスプロイトは改変されたsetuidバイナリの実行に依存するため、これにより最終的な権限昇格ステップがブロックされます。

これはOpenShift固有の機能ではありません — 通常のKubernetes（Pod Security Standards Restricted）、Docker（--security-opt no-new-privileges）、Podmanでも同様に機能します。OpenShiftは単に restricted-v2 SCCを介してデフォルトでこれを強制しますが、他のプラットフォームでは明示的な設定が必要です。

RHEL 8 / RHEL 9

RHEL 8およびRHEL 9には、脆弱なコードを含むカーネルが同梱されています。シェルアクセスを持つ権限のないローカルユーザーは、これを悪用してrootを取得できます。直ちにパッチを適用してください。

yum updateinfo list cves CVE-2026-31431
yum update kernel

OpenShift（4.x）

OpenShiftはRHCOS上で動作し、脆弱なカーネルが同梱されています。実際の影響は、ワークロードのSecurity Context Constraints（SCC）に依存します。

デフォルトの restricted-v2 SCCを使用する標準ワークロードは、allowPrivilegeEscalation: false が強制されるため、悪用できません。

昇格されたSCC（anyuid、privileged、または allowPrivilegeEscalation: true を許可するカスタムSCC）で実行されるPodは脆弱です。これには一般的に以下が含まれます:

• CI/CDビルドPod（Jenkinsエージェント、カスタムSCCを使用するTekton）
• anyuid を必要とするレガシーアプリケーション
• インフラストラクチャPod（モニタリング、ロギング、ストレージ）

ノードへの直接アクセス（例: oc debug node/ 経由）は常に脆弱です — 標準的なローカル権限昇格であり、コンテナ分離は関与しません。

テスト

クラスター内でエクスプロイトの前提条件が満たされているかどうかを確認するためのテストPodが提供されています。これは脆弱性の悪用を試みません — 以下のみをチェックします:

1. AF_ALG ソケットを作成できるか？（カーネル攻撃面に到達可能）
2. no_new_privs が設定されているか？（setuid昇格をブロック）
3. コンテナイメージにsetuidバイナリが存在するか？
4. 基盤となるノードのカーネルバージョン

使用方法（Pod）

oc apply -f test-pod.yaml
oc logs cve-2026-31431-check
oc delete -f test-pod.yaml

使用方法（Deployment）

Deploymentバリアントを使用して、レプリカをスケーリングするかPodアンチアフィニティを使用して複数のノードでテストします:

oc apply -f test-deployment.yaml
oc logs -l app=cve-2026-31431-check
oc delete -f test-deployment.yaml

終了コード

デフォルトのOpenShiftでの期待される結果

標準的なOpenShiftクラスターで restricted-v2 SCCを使用している場合、終了コード 1（部分的に露出）が表示されるはずです: AF_ALGソケットは作成できますが（RuntimeDefault seccompはこれをブロックしません）、no_new_privs がsetuid昇格ステップを防ぎます。公開されたPoCは機能しませんが、カーネルレベルの脆弱性には依然として到達可能です — パッチ適用が推奨されます。

緩和策

1. カーネルにパッチを適用（P0）

これが唯一の完全な修正です。すべてのノードのカーネルを更新し、再起動します。

OpenShiftの場合、修正を含むRHCOSバージョンに更新し、ローリングノード再起動を実行します。

2. algif_aeadモジュールを無効化（暫定回避策）

algif_aead がロード可能なモジュール（CONFIG_CRYPTO_USER_API_AEAD=m）としてコンパイルされている場合:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

これは algif_aead が組み込み（=y）の場合には機能しません。これはRHCOSの場合に該当します。以下で確認してください:

modinfo algif_aead 2>&1 | grep builtin
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

3. seccompでAF_ALGをブロック（OpenShift）

カーネルモジュールが組み込みの場合、パッチ適用前のコンテナ向けの唯一の緩和策は、カスタムseccompプロファイルを介して socket(AF_ALG, ...) システムコールをブロックすることです。

MachineConfigでseccompプロファイルをデプロイ

MachineConfigを作成して、すべてのノードにプロファイルを配置します（コントロールプレーンノードには role: master で繰り返します）:

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-worker-seccomp-deny-af-alg
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - path: /var/lib/kubelet/seccomp/deny-af-alg.json
          mode: 0644
          contents:
            source: data:application/json;charset=utf-8;base64,ewogICJkZWZhdWx0QWN0aW9uIjogIlNDTVBfQUNUX0FMTE9XIiwKICAic3lzY2FsbHMiOiBbCiAgICB7CiAgICAgICJuYW1lcyI6IFsic29ja2V0Il0sCiAgICAgICJhY3Rpb24iOiAiU0NNUF9BQ1RfRVJSTk8iLAogICAgICAiYXJncyI6IFsKICAgICAgICB7CiAgICAgICAgICAiaW5kZXgiOiAwLAogICAgICAgICAgInZhbHVlIjogMzgsCiAgICAgICAgICAib3AiOiAiU0NNUF9DTVBfRVEiCiAgICAgICAgfQogICAgICBdCiAgICB9CiAgXQp9

base64コンテンツは以下にデコードされます:

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

注: MachineConfigを適用すると、ローリングノード再起動がトリガーされます。

Pod仕様でプロファイルを参照

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: deny-af-alg.json

クラスター全体の代替案

Pod仕様を変更せずにすべてのコンテナを保護するには、既存のプロファイルにAF_ALGフィルタールールを追加して、MachineConfigを介してCRI-Oのデフォルトseccompプロファイル（/etc/crio/seccomp.json）を上書きします。

4. SCCを監査

昇格された権限で実行されているPodを特定します:

# restricted-v2を使用していないPodを検索
oc get pods -A -o json | jq -r '
  .items[] |
  select(.metadata.annotations["openshift.io/scc"] != "restricted-v2") |
  "\(.metadata.namespace)/\(.metadata.name) → \(.metadata.annotations["openshift.io/scc"])"
'

これらは、完全なエクスプロイトチェーンが機能するPodです。これらのワークロードを実行しているノードのパッチ適用またはseccomp緩和策を優先してください。

AF_ALG無効化の影響

AF_ALGソケットのブロックは、ほとんどのワークロードに無視できる影響しか与えません。以下は影響を受けません:

• dm-crypt / LUKS
• kTLS
• IPsec
• OpenSSL / GnuTLS（標準ビルド）

OpenSSL afalg エンジンを使用するように明示的に設定されたアプリケーションのみが影響を受けます。

参照

• Copy Fail — プロジェクトページ
• Red Hat CVE-2026-31431
• NVD — CVE-2026-31431
• RuntimeDefaultはAF_ALGをブロックしない（juliet.sh）
• Xint — Copy Fail解説
• The Register — Linux暗号コードの欠陥