SCTPhantom Mitigation for Yandex Managed Kubernetes

Yandex Managed Kubernetes クラスターのすべてのワーカーノード上の Linux kernel における脆弱性 CVE-2026-64564 (SCTPhantom) の緩和策を自動適用します。

脆弱性の説明

CVE 識別子 (CVE ID): CVE-2026-64564

CVE へのリンク: https://nvd.nist.gov/vuln/detail/CVE-2026-64564

元のレポート:

技術的な write-up (Tencent Zhuque Lab / Corvus AI): https://matrix.tencent.com/en/2026/08/06/sctphantom-CVE-2026-64564
公開 PoC (Debian 13、カーネル 6.12.95 上の LPE): https://github.com/ethanolgolf/CVE-2026-64564
Upstream フィックス (mainline): commit 9b2854f86f0b (net/sctp/sm_make_chunk.c 内)

概要:

SCTPhantom は、Linux カーネルの SCTP Dynamic Address Reconfiguration (ASCONF、RFC 5061) サブシステムにおける use-after-free であり、非特権のローカルユーザーがスーパーユーザー (root) 権限を取得できるようにするものです。

根本原因は、ASCONF チャンクの処理における識別情報の不一致です。DEL-IP 操作の検証は IPv4 パケットの送信元アドレス (S) に対して行われますが、その後の処理では Address Parameter (L) を介して選択された transport が使用されます。そのため、次の順序付けられたシーケンスは

[ Address Parameter L ] [ DEL-IP L ] [ DEL-IP 0.0.0.0 ]

検証を通過して transport(L) を削除し、その後ワイルドカード操作 DEL-IP 0.0.0.0 が、すでに解放されたポインターを「保存パス」として再利用します。その結果、asoc->peer.primary_path と asoc->peer.active_path は解放された struct sctp_transport へのダングリングポインターのままとなり、後続の getsockopt(SCTP_STATUS) 呼び出しがこれらを参照解除します。

脆弱なロジックは Linux 2.6.25 (2007 年、commit 42e30bf3463c) で導入されたため、約 18 年間カーネルに存在しています。

攻撃:

リモートアクセスは不要 - 非特権のローカルアカウントのみ
CAP_NET_ADMIN および CAP_SYS_ADMIN は不要で、デフォルトの seccomp プロファイルが有効な状態でも動作します。ASCONF と AUTH は SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED を介してソケットごとに有効化されるため、sysctl net.sctp.addip_enable を変更する必要はありません
コンテナからホストへの脱出が可能な実用的なプリミティブです: 著者らは 8 回中 6 回で host-root を取得しました。最終ステップは call_usermodehelper_exec() で、ホストの initial namespaces でプロセスを起動します
悪用に失敗した場合も kernel panic を起こさず「クリーンに」終了するため、検知が困難です
エクスプロイトチェーンは既存のカーネルコード (data-oriented な commit_creds()) を再利用し、shellcode や古典的な ROP は使用しません

影響を受ける技術:

Linux カーネル、net/sctp サブシステム (モジュール sctp)、net/sctp/sm_make_chunk.c での ASCONF 処理
モジュール sctp_diag (sctp に依存)。SCTP ソケットの検査に使用されます

この脆弱性は SCTP が利用可能な場合にのみ悪用可能です。モジュール sctp がロードされておらず、その自動ロードがブロックされている場合、攻撃ベクトルは利用できません。

著者らが確認した対象 (root 取得済み):

ディストリビューション	カーネル
Research kernel	Linux 7.2-rc2
OpenCloudOS-family	6.6.119
Debian 13	6.12.95+deb13-amd64
Rocky Linux 9 / RHEL 9	5.14 vendor kernel (`sctp` モジュールがロードされている場合)
Ubuntu 24.04	6.8.0-134-generic

修正済みカーネルバージョン:

ブランチ	最初の修正バージョン	Stable フィックス
6.6.y	6.6.148	`fedeb4468987`
6.12.y	6.12.101	`74e8f3e7114f`
6.18.y	6.18.42	`85aca407c560`
7.1.y	7.1.6	`d136b29bf91d`
mainline	7.2-rc5	`9b2854f86f0b`

ベンダーカーネルは、バージョン文字列が古くてもフィックスのバックポートを含む場合があります。カーネルのバージョンだけでは脆弱性の有無を判断するのに十分ではないため、ベンダーの advisory またはソースコードを確認してください。

CVSS v.4.0 による攻撃ベクトルと危険度:

基本評価: 8.5 (HIGH)

ベクトル: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

このフィックスの機能

DaemonSet はクラスターの各ワーカーノードで自動的に:

モジュールの状態をチェック - sctp と sctp_diag がロードされているか、refcnt がいくつかを確認します。このチェックは意図的にパッシブです。DaemonSet は、モジュールがまだロードされていないノードで自動ロードを誘発しないよう、ブラックリストを設定するまで SCTP ソケットを開きません
ノードで SCTP が使用されているかチェック - モジュールの refcnt と /proc/net/sctp/assocs および /proc/net/sctp/eps の生存エントリを分析します。Kubernetes 自体は SCTP を使用しませんが、ユーザーのワークロードが Service/Pod で protocol: SCTP を宣言する場合があります
脆弱なモジュールをブロック - sctp と sctp_diag に対する install および blacklist ルールを含む /etc/modprobe.d/blacklist-sctp.conf を作成します
モジュールをアンロード - sctp_diag、次に sctp の順で rmmod を実行します (順序が重要: sctp_diag は sctp に依存します)。生存中の SCTP 接続が検出された場合は、FORCE_APPLY=true が明示的に設定されていない限り、アンロードはスキップされます
緩和策を検証 - 設定ファイルの存在、modprobe sctp が拒否されること、および SCTP ソケットの作成 (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) がもはや成功しないことを確認します
状態を監視 - 毎時間設定ファイルの存在を確認し、消失した場合は復元し、モジュールが再びロードされている場合は再度アンロードします

重要: ノード上で起こり得る 2 つの結果

緩和策は 2 つの独立した部分で構成されており、一部のノードではそのうちの 1 つだけが適用されます。

1. ブラックリスト (常に適用、確実)。 /etc/modprobe.d/blacklist-sctp.conf が作成されると、モジュール sctp は socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP) による自動ロードでも、明示的な modprobe でも、もはやロードできなくなります。これにより、モジュールがまだロードされていないノード (典型的な状態: SCTP は Kubernetes では使用されておらず、オンデマンドでのみロードされる) で攻撃ベクトルが閉じられます。

2. メモリからのモジュールのアンロード (常に可能とは限りません)。 sctp がすでにロードされている場合、ほとんどの場合アンロードはできません。検証済みの Yandex Managed Kubernetes ノード (Ubuntu 22.04、カーネル 5.15.0-181-generic) では、ロード直後で誰にも使用されていないモジュール sctp でも、holders リストが空で /proc/net/sctp/{assocs,eps} が空の状態で既に refcnt=6 となっており、rmmod は ERROR: Module sctp is in use を返します。このカウンタは時間が経っても減少しません。

これには 2 つの帰結があります:

refcnt は SCTP の使用有無の指標ではありません。DaemonSet は情報提供のみを目的としてこれを出力し、アンロードの判断は /proc/net/sctp/assocs と /proc/net/sctp/eps の生存エントリに基づいて行います
sctp がすでにメモリに常駐しているノードでは、DaemonSet は正直に ⚠ mitigation applied PARTIALLY と報告します。ブラックリストはすでに設定されています (再起動後はモジュールは戻りません) が、再起動まではノードは脆弱なままです。攻撃ベクトルを完全に閉じるには、そのようなノードを再起動するか、node group を再作成する必要があります

適用後にそのようなノードを見つけるには:

kubectl logs -n kube-system -l app=cve-2026-64564-fix -c apply-fix --prefix | grep -E 'PARTIALLY|STILL LOADED'

ワークロードとの互換性

重要: この緩和策はノード上の SCTP を完全に無効化します。

Kubernetes およびネットワークプラグイン (Cilium、Calico) は独自の動作に SCTP を使用しないため、绝大多数のクラスターではこの緩和策は安全です。ただし、クラスター内に SCTP を使用するワークロード (例: テレコムアプリケーション、VoIP/SS7・Diameter シグナリング、protocol: SCTP を持つ Service または NetworkPolicy) がある場合、そのトラフィックは動作しなくなります。

適用前に、クラスター内にそのようなオブジェクトが存在するか確認するには:

# Service / Pod с protocol: SCTP
kubectl get svc -A -o json | jq -r '.items[] | select(.spec.ports[]?.protocol=="SCTP") | "\(.metadata.namespace)/\(.metadata.name)"'
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.containers[].ports[]?.protocol=="SCTP") | "\(.metadata.namespace)/\(.metadata.name)"'

# NetworkPolicy с protocol: SCTP
kubectl get netpol -A -o json | jq -r '.items[] | select((.spec.ingress[]?.ports[]?.protocol=="SCTP") or (.spec.egress[]?.ports[]?.protocol=="SCTP")) | "\(.metadata.namespace)/\(.metadata.name)"'

ノードで SCTP が使用されている場合、DaemonSet はデフォルトではモジュールをメモリからアンロードせず、ブラックリストのみを設定して (ノードの再起動後はモジュールは戻りません)、警告をログに書き込みます。既存の SCTP 接続を切断して強制的にアンロードするには、マニフェストで次のように設定します:

        env:
        - name: FORCE_APPLY
          value: "true"

クイックスタート

1. DaemonSet をダウンロード

wget https://raw.githubusercontent.com/yandex-cloud-examples/yc-mk8s-sctphantom-mitigation/main/sctphantom-mitigation-daemonset.yaml

またはリポジトリをクローン:

git clone https://github.com/yandex-cloud-examples/yc-mk8s-sctphantom-mitigation.git
cd yc-mk8s-sctphantom-mitigation

2. フィックスを適用

kubectl apply -f sctphantom-mitigation-daemonset.yaml

3. 適用ステータスを確認

# Проверить статус DaemonSet
kubectl get daemonset -n kube-system cve-2026-64564-fix

# Посмотреть на скольких нодах применен фикс
kubectl get pods -n kube-system -l app=cve-2026-64564-fix -o wide

4. フィックス適用のログを確認

# Логи initContainer (применение фикса)
kubectl logs -n kube-system -l app=cve-2026-64564-fix -c apply-fix

# Логи основного контейнера (мониторинг)
kubectl logs -n kube-system -l app=cve-2026-64564-fix -c monitor

5. 緩和策が完全に適用されていないノードを特定

kubectl logs -n kube-system -l app=cve-2026-64564-fix -c apply-fix --prefix | grep -E 'PARTIALLY|STILL LOADED|Skipping'

適用成功の例

=========================================
SCTPhantom (CVE-2026-64564) mitigation for Yandex Managed K8s
Node: demo-ru-central1-a-1
Date: Mon Aug 10 14:00:00 UTC 2026
FORCE_APPLY: false
=========================================

Step 1: Checking modules state before fix...
  [LOADED]   sctp (refcnt=0) - node is exposed
  [UNLOADED] sctp_diag

Step 2: Checking whether SCTP is in use on this node...
  ✓ No SCTP usage detected (expected: Kubernetes itself does not use SCTP)

Step 3: Applying the mitigation...
Created /etc/modprobe.d/blacklist-sctp.conf

Step 4: Unloading vulnerable modules...
  sctp_diag was not loaded (OK)
  sctp unloaded

yc-mk8s-sctphantom-mitigation

人気