【緊急】Linuxカーネル CVE-2025-39682：kTLSを使っているなら即更新 — 9月18日のKEV追加は3件、期限は本日9月21日

まず訂正です。CISAが2026年9月18日にKEV（悪用が確認された脆弱性のカタログ）へ追加したLinuxカーネルの脆弱性は、2件ではなく3件でした。

当サイトは9月18日の記事で CVE-2025-39964 と CVE-2026-53266 の2件を扱いましたが、同じ日に追加された3件目 CVE-2025-39682 を落としていました。あの記事を読んで2件だけ対処した方は、期限が本日9月21日の3件目が未対応のままになっています。

CVE-2025-39682 は、カーネルTLS（kTLS）の受信経路の欠陥です。対処は前2件と同じで、自分の版に修正パッケージが出ているかを確認したうえで更新し、再起動することです。

先に結論：自分に関係があるかの判定

この脆弱性は、カーネルTLS（kTLS）の受信を使っているときにだけ問題になります。一般的なWebサーバーの構成では、TLSはOpenSSLなどがユーザー空間で処理していて、kTLSは有効になっていないことが多くあります。

ただし「うちは使っていないはず」で済ませないでください。採番元のkernel.orgは、影響を受ける利用形態として OpenSSLのkTLS有効構成のサーバー／クライアント、NFS-over-TLS、net/handshake経由のSMB／RPC-over-TLS を挙げています。ストレージやファイル共有をTLSで通している環境は、意図せず該当していることがあります。

今すぐ行う対策

• ✓kTLSの受信を使っているか確認する。 Linuxカーネルの公式ドキュメントは、名前空間ごとの統計を `/proc/net/tls_stat` で公開していると記載しています。`TlsCurrRxSw` と `TlsCurrRxDevice` が現在張られているRXセッション数（それぞれホスト側で暗号処理・NIC側で暗号処理）、`TlsRxSw` と `TlsRxDevice` が累計で開かれたRXセッション数です。累計が0でなければ、過去に使われています。
• ✓自分の版が修正済みかを確認する。 下のリンクにあるディストリビューションのトラッカーで、使っている版とカーネル種別（generic／aws／azure など）の行を見ます。`Fixed` なら更新で閉じます。`Not affected` ならそのカーネルは対象外です。
• ✓該当するなら更新して再起動する。 カーネルは更新しただけでは切り替わりません。再起動するまで、動いているのは古いカーネルのままです。
• ✓再起動できたか確認する。 `uname -r` で現在動いているカーネルを表示し、更新後のパッケージ版と一致しているかを見ます。
• ✓9月18日の記事で扱った2件も、あわせて確認する。 CVE-2025-39964 と CVE-2026-53266 も期限は同じ本日9月21日です。3件は別々の修正なので、1つ直しても他は閉じません。
• ✓サポートが終了したカーネルを使っていないか確認する。 CISAはこの脆弱性についても、影響を受ける製品がEoL／EoSの可能性があり、その場合は使用の停止かサポート対象版への移行を推奨すると明記しています。

★評価が3者で割れている（9.8 / 7.1 / 7.0）

このCVEは、評価する主体によって深刻度だけでなく「攻撃元区分」まで食い違っています。当サイトが2026年9月21日に確認した時点の値です。

• ▸kernel.org（CNA）: 9.8 CRITICAL — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`。攻撃元はネットワーク（AV:N）
• ▸NIST（NVDのPrimary）: 7.1 HIGH — `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H`。攻撃元はローカル（AV:L）
• ▸Red Hat: 7.0（同社の脅威度は Moderate）— `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H`。ネットワークだが攻撃条件は高い（AC:H）

本記事の `cve_box` にはNISTの7.1を載せています。NVDにおける一次評価だからです。ただし、この値をそのまま鵜呑みにしないでください。

NVDでのこのCVEの状態は「Undergoing Analysis」（分析中）で、最終更新は2026年9月19日です。分析が進めば値が動く可能性があります。実際、同じ9月18日にKEV入りした CVE-2025-39964 は、9月19日にNISTの分析が完了して 3.3 LOW から 5.5 MEDIUM へ引き上げられました（当サイトも当初3.3で記事を出し、後から訂正しています）。

そして今回は、kernel.org側の根拠のほうが具体的です。

kernel.orgはCVEレコードに、各項目をその値にした理由を書いています。`AV:N` については 「バグはkTLSを有効にしたTCPソケット（net/tls RX経路）に、リモートの相手から届くTLSレコードの並びと中身だけで発火する。ローカルアクセスは不要」とし、`PR:N` については 「攻撃者はリモートのTLS相手であり、対象システム上の権限を一切持たない」としています。

NISTの `AV:L`（ローカル）とは前提がまったく違います。どちらが正しいかを当サイトが判定することはしませんが、kernel.orgは理由を明示しており、CISAはこれを悪用確認済みとして期限付きで登録しているという事実は押さえてください。

CISAはどう見ているか

CISAはKEVの登録にあわせて、2026年9月18日付でSSVC（判断支援の評価）を付けています。内容は Exploitation: active（悪用が実際に発生）／Automatable: yes（自動化可能）／Technical Impact: total（技術的影響は全面的） です。

また、このエントリには `forensicTriage: Yes` が付いており、CISAの是正指示は BOD 26-04 に従った対応と「Forensics Triage Requirements」の遵守を求めています。ランサムウェアでの利用は「Unknown」です。

何が起きるのか

欠陥は、kTLSの受信経路でゼロ長レコードを扱うところにあります。

kTLSの `recvmsg()` は、1回の呼び出しで「連続するDATAレコードだけ」か「DATA以外のレコード1つ」のどちらかを処理する決まりです。種別が変わったら処理を抜け、復号済みのレコードは `rx_list` に積んで次の `recvmsg()` に回します。ゼロコピーで復号した場合はユーザー空間のバッファへ直接書いているため `rx_list` に積むことができず、「ゼロコピーした後に種別の変化が判明することは無いはず」という前提で作られていました。その前提が崩れるのが、`rx_list` から取り出した最初のレコードがゼロ長だった場合です。

kernel.orgの説明によると、攻撃者は `[DATA]`・`[ゼロ長の非DATA]`・`[DATA]` の3レコードを連続して送るだけで、被害側が通常の `recvmsg()` ループを回している最中に決定論的に破壊が起きます。競合状態を勝ち取る必要もメモリ配置への依存もなく、修正と一緒に追加されたカーネルのセルフテストは一発で再現するとされています。TLS 1.2 は既定でゼロコピー可能なため、特殊なカーネル設定やソケットオプションも要りません。

結果として、kernel.orgは 解放済みのカーネルヒープがそのままユーザー空間のバッファへコピーされる（カーネルメモリの開示）、攻撃者が制御できる解放後書き込みとフリーリストの破壊、解放済みskbの二重解放によるoops／パニックを挙げています。弱点の種類は CWE-754（異常・例外条件の不適切なチェック） です。

★修正は1年以上前に出ている。今回のニュースは「悪用が確認された」ほう

CVE-2025-39682 がCVEとして公開されたのは2025年9月5日です。修正自体はその時点で上流に入っています。

つまり今回も、9月18日の記事で扱った2件と同じ形で、「新しい穴が見つかった」ではなく「前から直っていた穴が、実際に攻撃で使われていると確認された」というニュースです。長く再起動していないサーバーほど危ないということでもあります。

ディストリビューションの対応状況（2026年9月21日時点）

この脆弱性については、前2件と違って主要LTSの修正が出そろっています。当サイトが2026年9月21日に確認した内容です。

Ubuntu（主要パッケージ `linux`）: 24.04 LTS（noble）は `Fixed 6.8.0-86.87`、25.04（plucky）は `Fixed 6.14.0-34.34`。22.04 LTS（jammy）・20.04 LTS（focal）・18.04（bionic）は `Not affected`、26.04（resolute）・25.10（questing）も `Not affected` です。

Debian: bookworm は `6.1.153-1` で修正（DSA-6009-1）、trixie は `6.12.48-1` で修正（DSA-6008-1）。bullseye は注意が要ります。ソースパッケージ `linux` としては `(not affected)` ですが、`linux-6.1` は影響を受けており、`6.1.153-1~deb11u1` で修正されています（DLA-4328-1）。bullseyeで6.1系のカーネルを使っているなら対象です。リリース名だけでなく、自分が入れているソースパッケージ名まで見てください。

Red Hat: 脅威度は Moderate。RHEL 10 は `kernel-6.12.0-55.37.1.el10_0`、RHEL 9 は `kernel-5.14.0-570.49.1.el9_6` が対応版として挙がっています。RHEL 6・7・8 は `Not affected` です。

ここで「古いカーネルだから安全」「新しいから危ない」という読み方をしないでください。Ubuntu 22.04（5.15系）は `Not affected` ですが、Debian bookworm（6.1系）は影響を受けて修正が出ています。欠陥を作り込んだ変更が、どの安定版系列まで入っているかで決まるからです。

上に挙げたのは各ディストリビューションの主要パッケージの状態です。`linux-aws` や `linux-azure` のような種別ごとに状態は異なるので、必ず自分が使っている種別の行を見てください。

Debianのbullseyeがその典型です。同じリリースでも `linux` と `linux-6.1` で結論が逆になります。「リリース名で対象外だった」で止めると、実際には未修正のカーネルを動かし続けることになります。

★なぜ当サイトは3件目を落としたのか

原因は、KEVの調べ方です。9月18日の記事を書くとき、当サイトはCISAのKEVフィードを取得したうえで、あらかじめ決めておいたCVE番号を名指しで照会していました。そのため、同じ日に追加された3件目が視界に入りませんでした。取得したファイル自体には、最初から3件とも入っていました。

「探したいものを探す」と「その日に何が追加されたかを一覧する」は別の作業です。今回は前者しかやっていませんでした。以後は日付で絞って一覧し、件数を数えてから記事の対象を決めます。

9月18日の記事は「2件」の記述を「3件」に訂正し、本記事への案内を追記しました。

確度と、書かなかったこと

• ▸CVSSの3つの値は、いずれも2026年9月21日時点で当サイトが各一次情報を開いて確認した値です。NVDは「Undergoing Analysis」なので動きます。
• ▸回避策は書きません。公式が示していないカーネル設定の変更やモジュールの無効化を独自に案内すると、別の障害を生みます。kTLSを止められるかは、それを使っているソフトウェア側の設定の問題です。
• ▸悪用の具体的な手口や検知方法は扱いません。KEV入りが示すのは「実際の攻撃で悪用された」ことまでで、誰がどこまで権限を取ったかは公開情報から確定できません。
• ▸`/proc/net/tls_stat` のカウンタ名はLinuxカーネルの公式ドキュメント記載のものです。どのカウンタがこの欠陥の成立条件に直接対応するかまでは、公式に明示がないため書いていません。