悪用は未確認(11/2時点) この脆弱性は、米国CISAの「悪用が確認された脆弱性の一覧(KEV)」には載っていません。実際の攻撃に使われたという報告はまだありませんが、深刻度が高く、特に注意が必要なため取り上げています。

基本情報(データから表示)

CVE番号CVE-2026-98432
製品Linux カーネル
深刻度(CVSS)9.8 緊急CVSS v3.1
NVD に登録された、他の機関(開発元など)による評価
詳細(ベクター)CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
悪用の状況悪用の報告はまだ確認されていません(CISA の KEV に未掲載。11/2時点)
NVD に登録された日2026-10-15
弱点の種類(CWE)不明

何が起きた

Linux のカーネル(OS の中心部分)の、IPv4 の TCP の接続を受け付ける処理に、use-after-free(解放したメモリを使ってしまう誤り)の弱点が見つかりました。Linux のカーネルの公式の CVE の記録によると、IP オプション(通信に付ける追加の情報)付きの接続の要求が届き、同じ要求がもう一度送られてくると、返事を作っている途中で、すでに解放したメモリを読んでしまうことがあります。Linux のカーネルの CVE チームの評価では、ログインや利用者の操作がなくても、ネットワーク越しに起こせるとされています。Red Hat は、ログインしていない攻撃者が、カーネルのメモリを壊したり、システムをすぐに止めたりできるとしています。一方で、確実にプログラムを動かすには細かい条件が必要だともしています。AlmaLinux によると、この弱点を報告した Anthropic は、MPTCP で接続を待ち受けている Linux のサーバーで、遠くから root(管理者)として命令を実行できる攻撃の方法を示したと述べています。これは発見者が示した攻撃の方法で、実際の攻撃に使われたという報告は、まだ確認されていません(2026年11月2日の時点)。

攻撃の流れ

データをもとに、AIを使用して作成した図です。実際の攻撃は、これと異なる場合があります。

攻撃の流れ: 1. 攻撃者が IP オプション付きの接続の要求を送る → 2. 同じ要求をもう一度送る → 3. カーネルが解放したメモリを使ってしまう → 4. メモリが壊れたり、機器が止まったりするおそれがある1攻撃者が IP オプション付きの接続の要求を送る2同じ要求をもう一度送る3カーネルが解放したメモリを使ってしまう4メモリが壊れたり、機器が止まったりするおそれがある攻撃の流れ: 1. 攻撃者が IP オプション付きの接続の要求を送る → 2. 同じ要求をもう一度送る → 3. カーネルが解放したメモリを使ってしまう → 4. メモリが壊れたり、機器が止まったりするおそれがある1攻撃者が IP オプション付きの接続の要求を送る2同じ要求をもう一度送る3カーネルが解放したメモリを使ってしまう4メモリが壊れたり、機器が止まったりするおそれがある攻撃の流れ: 1. 攻撃者が IP オプション付きの接続の要求を送る → 2. 同じ要求をもう一度送る → 3. カーネルが解放したメモリを使ってしまう → 4. メモリが壊れたり、機器が止まったりするおそれがある1攻撃者が IP オプション付きの接続の要求を送る2同じ要求をもう一度送る3カーネルが解放したメモリを使ってしまう4メモリが壊れたり、機器が止まったりするおそれがある

誰が影響を受ける

Linux 4.4 以降のカーネル(修正の入った版を除く)を使っている機器が対象です。AlmaLinux は、信頼できないネットワークから IPv4 の TCP の接続を受け付けるシステムは、影響を受けると考えるべきだとしています。IPv6 の接続は、主な問題の影響を受けません。弱点はふつうの IPv4 の TCP の処理にあるため、MPTCP を使っていないシステムも修正が必要です。Red Hat は、Red Hat Enterprise Linux 8・9・10 と OpenShift が影響を受け、6 と 7 は影響を受けないとしています。なお、Go の公式のお知らせによると、Go 1.24 以降で作ったプログラムは、Linux では最初から MPTCP を使って接続を待ち受けます。

何をすればいい

使っている配布元(ディストリビューション)の公式の案内に従い、修正の入ったカーネルに更新して、再起動してください。Linux のカーネルの公式の記録では、修正は 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10、7.3 以降に入っています。Red Hat Enterprise Linux では、RHSA-2026:93414(8)、RHSA-2026:93412(9)、RHSA-2026:93413(10)で修正版が出ています。AlmaLinux は、10月30日に修正版のカーネルをテスト用の場所で先に公開し、確認が済んだら本番の場所に出すとしています(11月2日の時点で、AlmaLinux のセキュリティ情報の一覧にはまだ載っていません)。Debian は修正版を出しています(DSA-6568-1 など)。Ubuntu と SUSE は、11月2日の時点で、多くの版の修正がまだ準備中です。すぐに再起動できない場合、AlmaLinux は、IP オプション付きの IPv4 の TCP の通信を nftables(Linux で通信を通すか捨てるかを決めるしくみ)のルールで捨てる、一時的な対策を案内しています。Go の公式のお知らせは、Go のプログラムで MPTCP を止める方法も紹介していますが、確実な対策ではないとして、カーネルの更新を強く勧めています。

やることチェックリスト

  • 使っている Linux のカーネルの版を確かめる
  • 配布元の修正版のカーネルに更新して再起動する
  • すぐ更新できなければ配布元の一時的な対策を検討する

用語メモ

use-after-free 用語集で見る
一度使い終わって解放したメモリを、あとから誤って使ってしまう誤りです。メモリの中身が壊れたり、攻撃者にプログラムを動かされたりする原因になります。
MPTCP
Multipath TCP の略で、複数の回線を同時に使って、1つの TCP の通信を行うしくみです。
nftables
Linux で、届いた通信を通すか捨てるかなどの決まりを設定するしくみです。

次に読む

公式情報と元データ

公式情報

元データ(英語・NVD より)を開く

説明(NVD)

In the Linux kernel, the following vulnerability has been resolved: ipv4: free inet_opt and ireq_opt after an RCU grace period tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the child socket (newinet->inet_opt) without copying it. Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcp_check_req(). tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt under rcu_read_lock() only, and ip_build_and_send_pkt() and ip_options_build() then read opt->optlen twice. Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and inet_csk_reqsk_queue_drop() calls timer_delete_sync() before the child can be freed. Since commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table"), request sockets are processed without holding the listener lock, so nothing prevents the child socket from being freed while the SYNACK is still being built. TCP child sockets do not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt with a plain kfree(), leading to a use-after-free in ip_options_build(). A similar issue exists with request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program). reqsk_timer_handler() clones the request socket with inet_reqsk_clone(), so that the old request socket and its clone share the same ireq_opt, then reqsk_migrate_reset() clears the pointer in the old one. Another cpu holding a reference on the old request socket can still be using these options (sending a SYNACK, or creating a child in tcp_v4_syn_recv_sock()) when the clone is freed, and tcp_v4_reqsk_destructor() also uses a plain kfree(). Readers already use RCU, and other paths replacing inet_opt (do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use kfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor() as well. IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock() duplicates the options. tcp_v6_reqsk_destructor() has the same migration issue with ipv6_opt, which is only set by CALIPSO. This will be addressed in a separate patch.

この元データの出どころ: NVD で見る