Linuxカーネルの3件がまとめてKEV入り。kTLS受信経路のCVE-2025-39682、ebtables SNATのCVE-2026-53266、AF_ALGのCVE-2025-39964と3日期限の意味

2026年9月18日(米国時間)、CISAはLinuxカーネルの脆弱性3件を、同じ日にKnown Exploited Vulnerabilities(KEV)カタログへ追加しました。kTLSの受信経路にあるCVE-2025-39682、ebtablesのSNATターゲットにあるCVE-2026-53266、カーネル暗号APIのソケットインタフェースAF_ALGにあるCVE-2025-39964です。連邦民間行政機関(FCEB)への対応期限は3件とも2026年9月21日で、追加からわずか3日後でした。

3件のうち2件は2025年に公表され、上流カーネルでは同じ年のうちに修正されていたものです。それが1年近くたってから「実際に悪用されている」と認定されました。この記事は、Linuxサーバーやコンテナ基盤を運用するインフラ担当に向けて、3件がカーネルのどこで何を起こすのかを噛み砕き、ディストリごとの修正状況の確かめ方と、パッチまでの暫定の緩和策を整理します。事実関係はCISA、NVD、Red Hat、Ubuntu、Debianの一次情報で確認できたものに限り、確認できなかった点はその旨を書きます。

3件の早見表#

最初に、KEVの記載とNVDの登録内容を並べます。CVSSは評価者によって値が割れているため、出どころを併記しました。

NVDには、CISAがSSVCで付けた評価も掲載されています。3件とも悪用状況は「active」、技術的影響は「total」で、自動化可能性はCVE-2025-39682だけが「yes」、残る2件は「no」です。ランサムウェアでの利用有無は、KEV上では3件とも「Unknown」です。

KEVの3件の必要な措置(Required Action)には、ベンダーの指示に従って緩和策を適用すること、BOD 26-04と「Forensics Triage Requirements」に従うこと、緩和策がない場合は利用を中止することが書かれています。CVE-2025-39682とCVE-2026-53266の説明には、影響を受ける製品がサポート終了済みの可能性があり、サポート対象の版へ移行するよう求める一文も添えられています。

3日期限が示すもの#

期限を決めているのは、2026年6月10日に出された拘束的運用指令BOD 26-04です。この指令は、資産の公開状況、KEVに載っているか、悪用を自動化できるか、技術的影響の大きさを組み合わせて、同日から60日までの期限を割り当てます。3日の区分には「& forensic triage」という条件が付き、期限内の修正または緩和に加えて、その資産が侵害されていないかをフォレンジックの観点で確かめることまでが求められます。

KEVの3件にはいずれもforensicTriageの印が付いています。つまりCISAは、パッチを当てれば終わりとは見ていません。すでに足場を築かれたホストがある前提で、更新と侵害確認を別々の作業として扱うよう求めています。BOD 26-04は連邦機関向けの指示ですが、この「更新と点検を分ける」という枠組みは民間の環境にもそのまま流用できます。

なお、期限の9月21日はすでに過ぎています。民間組織がこの日付に縛られるわけではありません。また、3日という期限は作業量の見積もりではなく、悪用の確認を踏まえたリスクの区分です。社内では、影響するホストの範囲、外部への露出、緩和策の有無から自組織の期限を決め、間に合わないホストは例外として承認と理由を記録しておくと、後から説明できます。

優先順位づけでKEVとEPSSをどう組み合わせるかは、次の記事で整理しています。

CVE-2025-39682はkTLSの長さ0レコードの見落とし#

kTLSは、TLSの暗号化と復号をユーザー空間のライブラリではなくカーネルのソケット層で行う仕組みです。TCPソケットにTLSの上位層プロトコル(ULP)を取り付けると、受信したTLSレコードをカーネルが復号し、アプリケーションは通常のrecvmsg()で平文を受け取れます。Webサーバーが大きなファイルを暗号化したまま効率よく送るために使われることがあります。

修正コミットの説明によると、kTLSの受信処理には1回のrecvmsg()で扱うレコードについての約束があります。連続したアプリケーションデータ(DATA)のレコードなら何件でもまとめて処理してよく、アラートなどDATA以外のレコードは1回に1件だけ処理する、というものです。TLS 1.3では、レコードの種別は復号してみるまで分かりません。そこで、復号したあとで種別が変わったと分かったレコードは、rx_listという待ち行列に置いておき、次のrecvmsg()で取り出します。

さらに、DATAレコードはカーネル内のバッファを経由せず、利用者のバッファへ直接復号する「ゼロコピー」が許されています。直接書き込んだあとには待ち行列へ戻すための受け皿が残らないため、ゼロコピーはDATAレコードに限り、DATA以外のレコードを処理したら必ずループを抜ける、という前提で組まれていました。

見落とされていたのは、最初のレコードがrx_listから取り出され、しかも長さが0だった場合です。KEVの説明では、この長さ0のレコードがrecvmsg()の種別ごとの扱いをすり抜け、後続のレコードが誤ったゼロコピーと待ち行列の前提のまま処理されうる、とされています。Red Hatの説明によると、修正は呼び出しごとの種別を「未設定」を表す0で初期化して確認し、DATAのあとにDATA以外のレコードが来たら処理を打ち切るというものです。

NVDはこの欠陥をネットワーク経由、権限不要のCVSS 9.8と評価しています。一方でRed Hatは7.0(AV:N/AC:H)とし、kTLSを使っている場合に限ってリモートから誘発されうると明記しています。つまり、kTLSを有効にしていないホストでは、外部から直接この経路に届くことはありません。ただし、ローカルの利用者がkTLSのソケットを自分で作れば同じ処理を通せるため、共有ホストでは「kTLSを使っていないから無関係」とは言い切れません。

CVE-2026-53266はebtables SNATの書き込み先の取り違え#

ebtablesは、Linuxをブリッジ(L2スイッチ)として使うときに、ブリッジを通過するEthernetフレームへルールを適用するNetfilterの仕組みです。SNATターゲットは、フレームの送信元MACアドレスを書き換える機能で、オプションとしてARPパケットの中にある送信元ハードウェアアドレス(Sender Hardware Address)も一緒に書き換えられます。

修正コミットの説明によれば、送信元MACアドレスの書き換えは、パケットのデータが書き込み可能かを確かめる関数skb_ensure_writable()の保護の下で行われていました。ところが、ARPの送信元ハードウェアアドレスの書き換えはskb_store_bits()でskb->dataからの相対位置へ書き込むもので、その範囲が書き込み可能かは確かめられていませんでした。直前に使うskb_header_pointer()はARPヘッダを安全に読むだけの関数で、書き込み先を確保するものではありません。

問題は、書き込み先のデータがnonlinear(複数の断片に分かれた)ソケットバッファの断片にあり、その断片がsplice()でファイルから取り込まれたページを指している場合です。このときskb_store_bits()はそのページをそのままマップして新しいMACアドレスを書き込みます。splice()はデータをコピーせずにページを受け渡す仕組みなので、書き込まれるのはパケット用に確保した領域ではなく、ファイル由来の共有ページです。Red Hatはこの欠陥を「ARPハードウェアアドレスの書き換え時に共有メモリページへ書き込む」問題と表現し、ローカルの攻撃者による権限昇格、メモリ破壊、サービス停止につながると説明しています。修正は、ARPヘッダを読む前とskb_store_bits()を呼ぶ前に、該当範囲を書き込み可能にしておくというものです。

Red Hatは、悪用には特定のブリッジ用Netfilterルールが設定されている必要があるとしています。ebtablesのルールを設定するにはCAP_NET_ADMIN権限が要ります。非特権のユーザー名前空間を許しているホストでは、一般の利用者でも自分のネットワーク名前空間の中でこの権限を持てます。その経路でこの欠陥の前提条件を満たせるかどうかは、執筆時点で一次情報からは確認できていません。確認できない以上、ユーザー名前空間を開放しているホストでは、ルールを設定していなくても対象として扱う方が安全側です。

CVE-2025-39964はAF_ALGへの同時書き込み#

AF_ALGは、カーネルが持つ暗号アルゴリズムの実装を、ユーザー空間のプログラムからソケットとして呼び出すためのインタフェースです。ハッシュや共通鍵暗号の処理をカーネル側やハードウェアアクセラレータに任せたいときに使われ、特別な権限なしにソケットを開けます。

修正コミットの説明は短く、同じAF_ALGソケットへ2つの書き込みを同時に行うと、データが予測できない形で混ざり合い、ソケット内部の状態に不整合が生じうる、というものです。修正では、書き込みの排他的な所有権を表すctx->writeというフィールドを追加し、sendmsg()を同時に1つしか実行できないようにしました。NVDの構成情報では、影響は2.6.38以降の長い範囲に及びます。

Red Hatは、ローカルの利用者がこの欠陥を使ってシステムを停止させたり、暗号処理の結果を壊したりできると説明しています。NVD自身の評価は可用性への影響だけを見た5.5ですが、kernel.orgは機密性と完全性も高とする7.8を付け、CISAのSSVC評価も技術的影響を「total」としています。SSVCの「total」は、悪用によってソフトウェアの動作を全面的に制御されるか、情報を全面的に開示されうるという評価です。ただし、実際の悪用が停止だったのか権限昇格だったのかを含め、具体的な悪用手法は公表されていません。

ローカル起点の欠陥がKEVに載る意味#

3件のうち2件は、攻撃者がすでにそのホスト上でコードを動かせることが前提です。それでもKEVに載るのは、実際の侵入がたいてい段階を踏むからです。Webアプリの脆弱性、盗まれたSSH鍵、改ざんされた依存パッケージなどで一般ユーザーやコンテナ内の権限を得たあと、カーネルの欠陥でrootへ上がり、コンテナの外へ出て、ホスト全体と同じホストの他の利用者へ手を広げます。カーネルの権限昇格は、その2段目を担う部品として使われます。これは一般的な侵入の流れで、今回の3件が実際にどの段階で使われたのか、コンテナの外へ出る手段になったのかは公表されていません。

したがって、優先度を決める軸は「インターネットに公開しているか」だけでは足りません。「信頼できない利用者やコードが、そのカーネルの上で動く余地があるか」を見る必要があります。コンテナはホストとカーネルを共有するため、コンテナの中で動くコードにとってもホストのカーネルの欠陥は攻撃面です。

この構図は今回が初めてではありません。KEVカタログ(2026年9月22日版)に載るLinuxカーネルの項目は31件あり、2022年4月に追加されたDirty Pipe(CVE-2022-0847)や、2024年5月に追加されランサムウェアでの利用が「Known」とされたCVE-2024-1086も含まれます。2026年に追加された項目だけでも今回の3件を含めて8件あります。当サイトで7月に取り上げたepollの解放後使用Bad Epoll(CVE-2026-46242)は実証コードが公開されていましたが、執筆時点のKEVには載っていません。公表時の話題性とKEV入りの時期は一致せず、今回の2件のように1年近くたってから悪用が認定されることもあります。

優先して更新するホストの見極め#

カーネル更新には再起動が伴うため、全台を同時に進めるのは難しいのが普通です。次の順で優先度を付けると、限られた作業枠を攻撃面の大きい順に使えます。

SSHの踏み台やジャンプホストのように、利用者の数は少なくても特権への経路が集まるホストも、上の表で「高」として扱うのが妥当です。

ディストリごとの修正状況の確かめ方#

上流の修正版の番号は、ディストリのカーネルにはそのまま当てはまりません。各ディストリは修正をバックポートするため、自分が使う系列のパッケージの版で判断します。2026年9月23日の確認時点の状況は次のとおりです。

Ubuntuでは、同じリリースでも標準カーネル、HWEカーネル、クラウド向けカーネルといったパッケージごとに状態が異なります。リリース名だけで判断せず、稼働中のカーネルのパッケージ名で確認します。状況は日々更新されるため、作業の前に各トラッカーを直接確認してください。確認の手順は次のとおりです。

CVEの一次情報をどこで追うかは、次の記事にまとめています。

パッチまでの暫定の緩和策#

修正版が出ていない系列や、すぐに再起動できないホストでは、使っていない機能を止めることで攻撃面を減らせます。いずれも、その機能を業務で使っていないことを確かめてから適用してください。

kTLSについては、Red Hatがtlsモジュールの読み込みを止める方法を緩和策として示しています。まず grep CONFIG_TLS /boot/config-$(uname -r) でkTLSがモジュール(=m)として作られているかを確認し、lsmod でtlsモジュールが読み込まれていないかを見ます。モジュールであれば、Red Hatの手順に沿って、読み込み済みのtlsモジュールを modprobe -r で外し、modprobeの設定に blacklist tls と install tls /bin/false の2行を加えます。blacklistの行だけでは、ほかのモジュールの依存関係や必要時の自動読み込みで読み込まれる場合があるためです。カーネルに組み込み(=y)の場合はこの方法は使えません。OpenSSLのkTLSオプションを有効にしたWebサーバーなど、kTLSを意図して使っている環境では通信に影響するため、先に設定を確認します。

ebtablesについては、Red Hatが緩和策として、SNATルールでのARPハードウェアアドレスの書き換えを無効にするか、ブリッジのARPトラフィックに作用するSNATルールを削除する方法を挙げています。ebtables -t nat -L でnatテーブルのルールを確認し、ARPの書き換えを含むSNATルールがあれば見直します。ブリッジを使っていないホストでは、ebt_snatモジュールの読み込みを止める方法も考えられます。あわせて、非特権のユーザー名前空間を業務で使っていないホストでは、sysctlの user.max_user_namespaces で作成を制限すると、一般の利用者がCAP_NET_ADMINを持つ経路を閉じられます。ただしrootlessのコンテナや一部のブラウザのサンドボックスが動かなくなるため、用途を確かめてから適用します。

AF_ALGについては、Red Hatは使いやすさや安定性の基準を満たす緩和策はないとしています。AF_ALGを使うソフトウェアがないことを確認できるホストに限り、関連モジュールの読み込み停止や、seccompでAF_ALGソケットの作成を拒否する方法が候補になります。コンテナ環境では、ランタイムの既定のseccompプロファイルを外していないかを確認するのが先です。

コンテナ基盤では、コンテナにCAP_NET_ADMINを与えていないかも見直します。ネットワーク系のエージェントなど、本当にこの権限が要るコンテナだけに絞り、一般のアプリケーションのコンテナでは権限を落とした状態を既定にします。

権限を必要最小限に絞る考え方は、次の記事で扱っています。

恒久策として残しておきたい運用#

1つめは、カーネル更新を定期作業にすることです。今回のCVE-2025-39682とCVE-2025-39964は、2025年のうちにDebianやUbuntuで修正版が配られていました。修正版が出ている系列で、月に1回でもカーネルを更新して再起動する運用があれば、この2件はKEV入りの時点で対応が済んでいた可能性が高いと言えます。ただし、Red HatのCVE-2025-39964のように修正版の記載がない系列もあるため、更新の頻度だけで対応が完結するわけではありません。再起動を伴う更新を後回しにしない仕組みが、この種の「遅れて来る認定」への一番の備えです。

2つめは、使わないカーネル機能を最初から止めておくことです。kTLS、ブリッジ用のNetfilter、AF_ALG、非特権のユーザー名前空間は、多くのサーバーで使われていません。不要なモジュールの読み込みを止め、コンテナの権限を絞っておけば、次に同じ場所で欠陥が見つかったときも、パッチまでの時間を落ち着いて使えます。サーバーの堅牢化の全体像は次の記事で整理しています。

まとめ#

CISAは2026年9月18日に、Linuxカーネルの3件をKEVへ追加しました。kTLSの受信経路で長さ0のレコードが種別の確認をすり抜けるCVE-2025-39682、ebtablesのSNATがARPの送信元ハードウェアアドレスをファイル由来の共有ページへ書き込んでしまうCVE-2026-53266、AF_ALGソケットへの同時書き込みで内部状態が壊れるCVE-2025-39964です。期限は3日後の9月21日で、3件とも侵害の点検まで求める区分に入っています。

対応の順序は、稼働中のカーネルとディストリのトラッカーの突き合わせ、コンテナホストやCI runnerなど信頼できないコードが動くホストからの更新、修正版がない系列での機能停止や権限の絞り込み、そして最優先のホストでの侵害の点検です。まずは手元のコンテナホストで uname -r を実行し、トラッカーの修正版と比べるところから始めると、残りの作業の量が見えてきます。