LinuxカーネルのSCTP実装の脆弱性CVE-2026-64564

脆弱性の内容

Tencent Zhuque Labは技術解説で、SCTP（RFC 4960）を、多重ホームに対応し、1つの関連付けが複数の経路を持てる伝送プロトコルと説明した⁠［13］。RFC 5061の動的アドレス再構成では、ASCONFチャンクにアドレスパラメータと、ADD-IP・DEL-IP・SET-PRIMARYなどの操作を並べる⁠［13］。通称はSCTPhantomで、Corvus AIはTencentOS Security Team（Tencent Zhuque Lab）が共同で開発した多エージェントの脆弱性研究の仕組みである⁠［13］。

CNAが書いたCVEレコードの説明によると、sctp_process_asconf()は、ASCONFチャンクを処理するtransportをasconf->transportに保持する⁠［1］。アドレスパラメータで見つけたASCONFでは、このtransportがパケットの送信元アドレスと一致しないことがある⁠［1］。

CNAの説明では、1つのASCONFに[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]を並べると、DEL-IP Lがtransportを解放する⁠［1］。続くワイルドカードのDEL-IPは、解放済みのポインタを再び使う⁠［1］。関連付けのprimary_pathとactive_pathは、解放済みのメモリを指したまま残る⁠［1］。

攻撃者の位置と影響の説明

CNAは、攻撃元の評価をネットワークとした理由を、確立した関連付けの上で遠隔のピアが細工したASCONFを送って起こせるためと説明した⁠［1］。

Red HatのCVEデータによると、遠隔の攻撃者は、細工したASCONFチャンクの並びを送ってuse-after-freeを起こせる⁠［2］。このメモリの破壊はシステムのクラッシュによるサービス拒否につながる可能性があり、任意のコード実行に至るおそれもある⁠［2］。

TencentOS Security Teamの研究者はoss-securityへの投稿で、影響を、ローカルの低権限ユーザーによるrootの取得と、コンテナからホストのrootの取得とした⁠［15］。誘発は決定的で、ローカルの低権限のアクセスを要し、利用者の操作は要らないと書いた⁠［15］。GovCERT.HKは警報A26-08-15で、SCTPhantomにより低権限のローカルの攻撃者がrootを取り、脆弱なコンテナからホストへ脱出しうると説明した⁠［11］。

The Hacker Newsの8月7日の記事によると、同じ欠陥を扱うopenKylinの告知は、カーネルパニックとサービス拒否までしか書いていない⁠［19］。

発見者による攻撃の実証

Tencent Zhuque Labの技術解説では、攻撃の連鎖はuse-after-freeからカーネルの読み出しとKASLRの回避を経て、commit_creds()でrootを取る⁠［13］。続いてusermode-helperの変種で、コンテナからホストへ脱出する⁠［13］。連鎖は既存のカーネルのコードを使い、ユーザー空間のシェルコードも従来のROPチェーンも要さない⁠［13］。

Tencent Zhuque Labは、初期のPoCがsysctlのnet.sctp.addip_enableとnet.sctp.addip_noauth_enableを有効にしていたため、CAP_NET_ADMINが必要に見えたと書いた⁠［13］。Corvus AIは後に、両方を変えない経路を見つけた⁠［13］。Linuxカーネルの文書は、動的アドレス再構成を使うには、両端でaddip_enableとaddip_noauth_enableを有効にするか、対応するsetsockoptを使うと定めている⁠［21］。

Tencent Zhuque Labのコンテナ脱出の試験では、既定のseccompプロファイルを有効にしたまま、コンテナにCAP_NET_ADMINもCAP_SYS_ADMINも与えなかった⁠［13］。8回の試行のうち6回でホストのrootに達した⁠［13］。失敗した2回は、カーネルパニックを起こさずに止まった⁠［13］。

TencentOS Security Teamの研究者はoss-securityへの返信で、攻撃コードはCAP_NET_ADMINを要さないと答えた⁠［18］。細工したパケットを組むためにCAP_NET_RAWを要し、別のネットワーク名前空間は必須でないとした⁠［18］。Dockerは既定でCAP_NET_RAWを与え、攻撃コードはコンテナの中から動いてコンテナ脱出に至るとも書いた⁠［18］。

目次へ

時系列

目次へ

対象の製品と版

CNAはCVEレコードで、影響をLinux 2.6.25からとし、欠陥のあるファイルをnet/sctp/sm_make_chunk.cとした⁠［1］。

Tencent Zhuque Labは、ベンダーのカーネルは古い版の名のまま修正を移植することがあり、版の文字列だけでは影響の有無を決められないと書いた⁠［13］。他の環境での影響は、SCTPの可否、rawとpacketのソケットの利用、ユーザー名前空間の方針、seccomp、capabilities、LSMの方針で変わるとした⁠［13］。

既定の設定と影響の範囲

Red Hatは、標準のインストールではSCTPのカーネルモジュールは既定で読み込まれず、影響はSCTPを使う環境か、一般利用者がモジュールの読み込みを起こせる環境に限られると説明した⁠［2］。Openwallの投稿者はoss-securityで、RHEL系ではSCTPモジュールが通常のインストールに含まれず、kernel-modules-extraにあると書いた⁠［16］。そのパッケージのblacklistの設定が、一般利用者による自動読み込みを防ぐ⁠［16］。影響の範囲はディストリビューションで異なりうるとも書いた⁠［16］。

CIQの8月7日の案内では、CIQの企業向け製品でsctpモジュールが既定で読み込み禁止になっている⁠［8］。多くのCIQのシステムはSCTPを読み込んだことがなく、影響を受けないとした⁠［8］。悪用にはローカルのコード実行とSCTPモジュールの読み込みが要り、SCTPは電気通信の信号処理（SS7/SIGTRAN）などで使われる⁠［8］。

腾讯云は通告で、sctpモジュールが読み込まれていなければ、その環境は影響を受けないと説明した⁠［10］。

配布元の対応

目次へ

悪用の状況

The Hacker Newsは8月7日の記事で、執筆の段階では公開の攻撃コードが出ておらず、CISAのKEVにもこの欠陥の登録が無いと報じた⁠［19］。

CloudLinuxの8月31日のブログによると、攻撃の連鎖全体のPoCが8月7日から公開されている⁠［9］。CloudLinux 7とCloudLinux for Ubuntu 22.04では一般利用者がSCTPモジュールを読み込める⁠［9］。公開の攻撃コードは非特権のユーザー名前空間を要し、両者ではそれを無効にしているため、攻撃は失敗する⁠［9］。

CISA ADPは10月16日、CVEレコードのSSVCで悪用（Exploitation）を「none」とした⁠［1］。自動化の可否（Automatable）は「yes」、技術的な影響（Technical Impact）は「total」である⁠［1］。

NVDの11月3日の更新では、状態は「Awaiting Analysis」で、NVD自身の評価は無く、CNAの値とCISA ADPのSSVCが載っている⁠［12］。KEVへの登録を示す項目（cisaExploitAdd）は無い⁠［12］。

GovCERT.HKは同じ警報で、PoCの公開が報じられたのはZapscape（CVE-2026-64561）だと書いた⁠［11］。

目次へ

修正と回避策

CNAはCVEレコードで、修正を、ASCONFの処理中のtransportを対象にするDEL-IPを拒否するものと説明した⁠［1］。Tencent Zhuque Labの技術解説では、修正後のコードは、DEL-IPの対象がASCONFの保持するtransportと同じならSCTP_ERROR_REQ_REFUSEDを返す⁠［13］。mainlineのコミットは9b2854f86f0bである⁠［13］。

配布元と発見者の研究者は、sctpモジュールの読み込みを止める緩和策を示した⁠［2、5、10、17］。

• Red Hatは、sctpモジュールの読み込みを禁じる設定を置き、initramfsを作り直して再起動する手順を示し、SCTPを使うアプリケーションはこの緩和策を使えず、修正の適用を優先するよう求めた⁠［2］。
• Ubuntuは、sctpモジュールが不要なら再起動後も読み込みを禁じ、読み込み済みで使っていなければモジュールを外すよう示した⁠［5］。
• 腾讯云は、sctpモジュールの読み込みの禁止を挙げ、SCTPに依存する一部の電気通信の信号処理の業務が動かなくなることがあると注記した⁠［10］。
• TencentOS Security Teamの研究者は、SCTPを読み込み式のモジュールにしているシステムでは、sctpモジュールを外して読み込みを禁じれば悪用を緩和できるはずだと答えた⁠［17］。

腾讯云は、T-Sec主机安全がこの脆弱性の検知と自動修復に対応したと説明した⁠［10］。

目次へ

未公表の事項

• CloudLinuxが8月7日から公開と書いた攻撃コードの公開元
• Tencent Zhuque Labがコンテナ脱出の試験に使ったコンテナランタイム
• Ubuntu 20.04 LTS以前とCloudLinux 7の修正の時期

注

• 〔注1〕発見者のoss-securityへの投稿は、CVE告知が挙げる最初の修正版を6.6系から7.1系までと7.2-rc5とし、5.10・5.15・6.1系を挙げていない⁠［15］。

出典

更新記録

• 2026年8月13日：公開した。
• 2026年8月19日：CNAが8月19日に更新したCVEレコード（出典1）の修正版の一覧で、「対象の製品と版」の表3を改めた。
• 2026年8月31日：CloudLinuxの8月31日のブログ（出典9）を加え、公開のPoCと攻撃コードの条件を「悪用の状況」に、Amazon Linux（出典7）のAmazon Linux 2023の修正を「時系列」と「対象の製品と版」に加えた。
• 2026年9月24日：Red HatのCVEデータ（出典2）に載ったRHELの修正を「時系列」と「対象の製品と版」に加えた。
• 2026年10月1日：Amazon Linux（出典7）のAmazon Linux 2の修正を「対象の製品と版」に加えた。
• 2026年10月19日：CVEレコード（出典1）に加わったCISA ADPのSSVCとCWEを「脆弱性の内容」と「悪用の状況」に加えた。
• 2026年10月27日：Red HatのCVEデータ（出典2）に載ったOpenShift Container Platformの修正を「時系列」と「対象の製品と版」に加えた。
• 2026年10月29日：CloudLinuxのブログの10月29日の更新（出典9）で、Ubuntu 22.04の修正カーネルの公開を「時系列」に、CloudLinux 7の状態を「対象の製品と版」に加えた。
• 2026年11月3日：NVDの11月3日の更新（出典12）の状態を「悪用の状況」に加えた。
• 2026年11月6日：Ubuntuのページの11月6日の更新（出典5）で、Ubuntuの各版の状態を「対象の製品と版」で改めた。

目次へ

関連記事

同じ当事者の資料を引く記事

• LinuxカーネルのIPv4 TCP処理の脆弱性CVE-2026-98432（CVE Program）

  判明 2026年10月15日 公開 2026年11月1日 脆弱性の公表、AI関連、国外