⚡ CVE-2026-74469 — `DiagSpill`

Linux カーネル SCTP ピアトランスポートカウントオーバーフロー

Linux カーネルの SCTP 脆弱性は、16 ビットのピアトランスポートカウンタのオーバーフローによって引き起こされ、カウンタが 65535 から 0 へラップアラウンドすることを可能にします。SCTP 診断ダンプ中に、ラップした値が skb ペイロードの予約不足を引き起こし、続いてピアアドレスデータの境界外書き込みが発生する可能性があります。

⚠️ 免責事項

このリポジトリは、許可されたセキュリティ研究、カーネル脆弱性分析、 CTF 環境、カーネルデバッグ、および防御的テストのみを目的としています。

明示的な許可なく、システムに対して概念実証コードを使用しないでください。

📌 脆弱性の概要

Linux カーネル CVE アドバイザリでは、この問題を SCTP における 16 ビットの transport_count オーバーフローとして説明しており、それに続いて INET_DIAG_PEERS の過小な割り当てと、診断ダンプ中の境界外書き込みが発生します。

🧬 脆弱性の説明

脆弱なコードは、一意のピアトランスポートの数を 16 ビットカウンタで管理しています:

transport_count

新しく追加された一意のピアごとにカウンタがインクリメントされます。

重要な境界は次のとおりです:

さらに別の一意のトランスポートを追加すると、次のようになります:

65535 + 1
     ↓
     0

結果として生じるラップアラウンドは、次の間に不整合を生み出します:

transport_count

および:

transport_addr_list

診断サブシステムは後に、応答バッファのサイズを計算する際にラップしたカウンタを信頼しますが、ピアアドレスの完全なリストを反復処理し続けます。

🔬 根本原因

脆弱性は次のように表すことができます:

                    SCTP Association
                           │
                           ▼
                 Add unique peers
                           │
                           ▼
                 transport_count
                    uint16_t
                           │
                           ▼
                    65,535 peers
                           │
                           ▼
                 + 1 unique peer
                           │
                           ▼
                    Integer wrap
                           │
                           ▼
                transport_count = 0
                           │
                           ▼
                  SCTP sock_diag
                           │
                           ▼
             Reserve incorrect payload
                           │
                           ▼
          Iterate complete peer list
                           │
                           ▼
             Out-of-bounds skb write

アップストリームのアドバイザリでは、65,536 番目のトランスポートがカウンタをゼロにラップさせると明記されています。

🧠 バグが発生する理由

診断コードは事実上、同じ状態に対する 2 つの異なるビューに依存しています。

割り当て側

transport_count
       │
       ▼
payload size

コピー側

transport_addr_list
       │
       ▼
copy every peer address

整数がラップした後:

transport_count = 0

transport_addr_list =
    [peer 1]
    [peer 2]
    [peer 3]
    ...
    [peer 65536]

したがって、アロケータは次の基準で領域を予約します:

0 peers

一方、コピー操作は依然として次の処理を行う可能性があります:

65536 peer addresses

この不一致がメモリ安全性違反を引き起こします。

💥 メモリ破壊

Linux カーネルアドバイザリでは、結果として生じる診断ダンプが空のペイロードを予約し、その後 約 8 MiB のピアアドレスを skb テールを超えて書き込むと説明されています。

概念的には:

Expected skb:

┌───────────────────────────────┐
│ INET_DIAG header              │
├───────────────────────────────┤
│ Peer addresses                │
└───────────────────────────────┘
              ▲
              │
          valid end


Actual vulnerable state:

┌───────────────────────────────┐
│ INET_DIAG header              │
└───────────────────────────────┘
              ▲
              │
          skb tail

              ↓
      Peer address writes
              ↓
      Peer address writes
              ↓
      Peer address writes
              ↓
      OUT-OF-BOUNDS WRITE

Red Hat はこの欠陥を CWE-787: 境界外書き込み に分類しています。

🔎 脆弱なコードパス

関連するパスは次のように要約できます:

SCTP association
      │
      ▼
sctp_assoc_add_peer()
      │
      ▼
transport_count++
      │
      ▼
16-bit overflow
      │
      ▼
SCTP sock_diag
      │
      ▼
INET_DIAG_PEERS
      │
      ▼
skb payload reservation
      │
      ▼
transport_addr_list iteration
      │
      ▼
Out-of-bounds write

影響を受けるソースファイルは次のとおりです:

net/sctp/associola.c

Linux カーネル CVE の発表では、このファイルが明示的に特定されています。

🩹 アップストリーム修正

アップストリームの修正は次のとおりです:

bd0e9289e2642f6a5c54faad304ce0f41e926d22

コミット:

sctp: prevent peer transport count overflow

この修正は、次の場合に新しい一意のピアを拒否します:

transport_count >= U16_MAX

重要なのは、このチェックが 既存ピアの検索後 に行われることです。

これにより、アソシエーションが上限に達した場合でも、既に存在するトランスポートを取得する機能が維持されます。

🛡️ パッチのロジック

脆弱

New peer
   │
   ▼
transport_count++
   │
   ▼
Possible 16-bit wrap
   │
   ▼
Diagnostic size mismatch
   │
   ▼
OOB write

修正済み

New peer
   │
   ▼
Existing peer?
   │
 ┌─┴──────────┐
 │            │
YES           NO
 │            │
 ▼            ▼
Reuse       Check U16_MAX
transport       │
                ▼
          Reject at limit

重要なセキュリティ特性は、既存ピアの通常の検索セマンティクスを維持しつつ、カウンタがラップすることを決して防ぐことです。

📊 脆弱 vs 修正済み

💥 セキュリティへの影響

メモリ破壊は潜在的に次の結果をもたらす可能性があります:

カーネルクラッシュ
サービス拒否
カーネルメモリ破壊
境界外カーネル書き込み
潜在的な権限昇格
潜在的なカーネルコード実行

開示後に公開された研究では、特定の条件下でのローカル root 権限昇格が報告されていますが、元の Linux カーネル CNA スコアリングでは AV:L/AC:H/PR:L/UI:N が使用されています。

この脆弱性は、非常に特定の SCTP/アドレス設定の状況下で潜在的にリモートから到達可能であるとも説明されていますが、これは一般的にリモートで悪用可能な脆弱性と同等に扱うべきではありません。

🧪 研究環境

推奨される分離トポロジ:

┌───────────────────────────────────────────┐
│              Linux VM                    │
│                                           │
│       ┌───────────────────┐               │
│       │   SCTP Association │               │
│       └─────────┬─────────┘               │
│                 │                         │
│                 ▼                         │
│       ┌───────────────────┐               │
│       │ Multiple SCTP      │               │
│       │ Peer Transports    │               │
│       └─────────┬─────────┘               │
│                 │                         │
│                 ▼                         │
│       ┌───────────────────┐               │
│       │   SCTP sock_diag   │               │
│       └─────────┬─────────┘               │
│                 │                         │
│                 ▼                         │
│          INET_DIAG_PEERS                  │
│                                           │
└───────────────────────────────────────────┘

便利なツール:

ip sctp
ss
ss -a
ss -A sctp
dmesg -w
gdb
pwndbg
crash

SCTP サポートの確認:

lsmod | grep sctp

カーネル設定の確認:

grep CONFIG_IP_SCTP /boot/config-$(uname -r)

🔎 カーネルの検証

実行中のカーネルの確認:

uname -r

SCTP 設定の確認:

grep -E 'CONFIG_IP_SCTP|CONFIG_SCTP' \
/boot/config-$(uname -r)

ロードされた SCTP モジュールの確認:

lsmod | grep -i sctp

SCTP ソケットの検査:

ss -A sctp

🧪 再現ワークフロー

制御されたカーネル研究の場合:

01. Build vulnerable kernel
          ↓
02. Boot isolated VM
          ↓
03. Enable SCTP
          ↓
04. Create controlled SCTP association
          ↓
05. Populate unique peer transports
          ↓
06. Reach transport-count boundary
          ↓
07. Trigger SCTP diagnostic dump
          ↓
08. Monitor skb diagnostics
          ↓
09. Capture kernel behavior
          ↓
10. Apply upstream fix
          ↓
11. Repeat test
          ↓
12. Compare vulnerable vs patched

カーネル出力の監視:

sudo dmesg -w

デバッグの場合:

gdb vmlinux

または:

pwndbg vmlinux

📂 リポジトリ構造

CVE-2026-74469-DiagSpill/
│
├── README.md
│
├── exploit/
│   ├── poc.c
│   └── Makefile
│
├── analysis/
│   ├── root-cause.md
│   ├── sctp-transport-count.md
│   ├── sock-diag.md
│   ├── skb-overflow.md
│   └── patch-analysis.md
│
├── kernel/
│   ├── vulnerable/
│   └── patched/
│
├── lab/
│   ├── setup.sh
│   ├── cleanup.sh
│   └── topology.md
│
├── screenshots/
│
├── docs/
│   └── research-notes.md
│
└── LICENSE

🛡️ 緩和策

主な緩和策は、アップストリームの修正を含むカーネルにアップグレードすることです。

Debian/Kali の場合:

sudo apt update
sudo apt full-upgrade

その後再起動:

sudo reboot

確認:

uname -r

SCTP が不要な場合、管理者は環境と運用要件に応じて、影響を受ける SCTP 機能を無効化することも検討できます。公開研究では、これらのコンポーネントが未使用の場合の即時緩和策として、SCTP / sctp_diag の無効化が具体的に挙げられています。

📦 修正済みカーネルリリース

アップストリームの安定版発表では、以下の修正済みリリースがリストされています:

これらのバージョンは Linux カーネル CVE の発表によるものです。ディストリビューションは、異なるバージョン番号のパッケージに修正をバックポートする場合があります。

🧩 セキュリティの教訓

01 — 境界付きカウンタが暗黙的にラップすることを決して許してはならない

16 ビットカウンタには厳格な最大値があります:

U16_MAX = 65535

セキュリティ上重要なコードは、この境界を明示的に処理する必要があります。

02 — 割り当て数とコピー数は一致しなければならない

バッファの割り当てに使用されるサイズは、実際にそこにコピーされるオブジェクトの数に対応していなければなりません。

03 — 診断インターフェースはセキュリティ上重要である

カーネル診断 API は、内部状態が不整合になると、メモリ破壊の攻撃対象面になる可能性があります。

04 — 整数バグはメモリ安全性バグになり得る

元のプリミティブは整数オーバーフローですが、結果として生じるセキュリティへの影響はカーネルの境界外書き込みです。

05 — カーネルネットワーク状態は複雑である

SCTP アソシエーションは大量のピアトランスポートの集合を含む可能性があり、カウンタの制限とリスト管理ロジックがセキュリティ上重要になります。

📚 参考文献

CVE: CVE-2026-74469
コードネーム: DiagSpill
サブシステム: Linux SCTP
影響を受けるファイル: net/sctp/associola.c
主要関数: sctp_assoc_add_peer()
修正: sctp: prevent peer transport count overflow
アップストリーム修正: bd0e9289e2642f6a5c54faad304ce0f41e926d22
CWE: CWE-787 / 境界外書き込み
Linux カーネル CVE アドバイザリ: CVE-2026-74469 advisory
Debian セキュリティトラッカー: CVE-2026-74469 Debian tracker
Red Hat: CVE-2026-74469 Red Hat advisory

⚡ DiagSpill

CVE-2026-74469

Linux Kernel · SCTP · sock_diag · OOB Write · Kernel Security

Research • Analyze • Reproduce • Harden

CVE	CVE-2026-74469
コードネーム	DiagSpill
コンポーネント	Linux Kernel
サブシステム	SCTP / sock_diag
影響を受けるファイル	`net/sctp/associola.c`
主要関数	`sctp_assoc_add_peer()`
バグクラス	整数オーバーフロー / 境界外書き込み
影響	カーネルメモリ破壊
潜在的な影響	ローカル権限昇格
CVSS v3.1	7.0 — High
攻撃ベクトル	ローカル
攻撃の複雑さ	高
必要な権限	低
ユーザー操作	なし
ステータス	修正済み

16 ビットトランスポート制限の適用	❌	✅
カウンタのラップ防止	❌	✅
既存ピアが引き続き使用可能	✅	✅
診断ペイロードサイズの信頼性	❌	✅
OOB skb 書き込みの防止	❌	✅
カーネルメモリ破壊の緩和	❌	✅

5.10	5.10.265
5.15	5.15.216
6.1	6.1.183
6.6	6.6.151
6.12	6.12.103
6.18	6.18.44
7.1	7.1.8
7.2	7.2-rc6

CVE-2026-74469

人気

⚡ CVE-2026-74469 — DiagSpill

Linux カーネル SCTP ピアトランスポートカウントオーバーフロー

⚠️ 免責事項

📌 脆弱性の概要

🧬 脆弱性の説明

🔬 根本原因

🧠 バグが発生する理由

割り当て側

コピー側

💥 メモリ破壊

🔎 脆弱なコードパス

🩹 アップストリーム修正

🛡️ パッチのロジック

脆弱

修正済み

📊 脆弱 vs 修正済み

💥 セキュリティへの影響

🧪 研究環境

🔎 カーネルの検証

🧪 再現ワークフロー

📂 リポジトリ構造

🛡️ 緩和策

📦 修正済みカーネルリリース

🧩 セキュリティの教訓

01 — 境界付きカウンタが暗黙的にラップすることを決して許してはならない

02 — 割り当て数とコピー数は一致しなければならない

03 — 診断インターフェースはセキュリティ上重要である

04 — 整数バグはメモリ安全性バグになり得る

05 — カーネルネットワーク状態は複雑である

📚 参考文献

⚡ DiagSpill

CVE-2026-74469

0xBlackash

⚡ CVE-2026-74469 — `DiagSpill`