CVE-2026-98432を機に考えるIPv4 IP Options：RFCから読み解くフィルタリングの考え方

2026年10月に公表されたLinuxカーネルのIPv4 TCP処理の脆弱性（CVE-2026-98432）は、認証されていないリモートの攻撃者によって、システム停止やメモリ破壊、リモートコード実行につながる可能性がある深刻な脆弱性です。本記事を執筆している2026年11月10日時点で、Red HatおよびUbuntuではCVSS v3.1基本値9.8（Critical）と評価されています。

Red HatやUbuntuから、修正版カーネルを適用するまでの暫定的な緩和策として「ファイアウォールなどで、IP Optionsが付いたIPv4 TCPパケットを遮断する」方法が示されており、弊社の製品でも緩和策としてご案内しています。ただし、この対策は脆弱性を完全に回避するものではなく、修正版カーネルの適用に代わるものではありません。

この緩和策を聞いて「IP Optionsとはそもそも何なのか」と思われた方もいるのではないでしょうか。

この記事では、IP Optionsとはどのような場合に使われる機能なのか、そして暫定的な緩和策として遮断した場合、実際の環境の業務通信へどのような影響が生じ得るのかについて考えます。まず最初に筆者の結論を述べ、その後、IPv4技術の歴史とRFCに記された内容をひもときながら、結論に至った根拠を順に説明します。

1. CVE-2026-98432の緩和策として「IP Options付きIPv4 TCP通信を遮断」して問題ないのか

結論から述べると、外部攻撃者から到達可能なインターネット公開サーバーで直ちに修正版カーネルを適用することが難しい場合には、暫定的なリスク低減策として「IP Optionsを含むIPv4 TCP通信を遮断する」ことは、CVE-2026-98432の緩和策として有効であり、遮断によって業務上の問題が生じるリスクも低いと考えます。

この結論は、「遮断が緩和策として有効であること」と「遮断しても業務への影響が小さいこと」の2点から成ります。前者は、冒頭で述べたとおりRed HatやUbuntuが、修正版カーネルを適用するまでの暫定的な緩和策として示している方法です。後者については、RFCの記述と筆者の運用経験をもとに、次のように考えます。

IP OptionsにはRecord Route、Source Routing、Timestampなどがあり、後述するRFCでは、そのうち複数についてネットワーク機器でデフォルトのdropが推奨されています。一方、Router Alert Optionなど、特定の環境で実際に必要とされるIP Optionsもあるため、「IP Optionsは常にすべて遮断すべき」と一般化するのは適切ではありません。ただし、Router Alert Optionも管理されたネットワーク内での利用に限るべきとされています。したがって、外部の不特定な送信元からインターネットを越えて到達するIP Optionsを許可する必要は、現実的にはほとんどないのではないかと考えます。

そのうえで、外部の不特定な送信元から到達するインターネット境界という条件に限定すれば、IP Options付きIPv4パケットを一律に遮断する運用は、セキュリティ上合理的な選択肢の一つであると筆者は考えます。

なお、組織内部のネットワークではIP Optionsが利用されている可能性も考えられるため、遮断してよいかどうかは、事前に利用状況を確認してから判断する必要があると考えます。

また、一つ実経験の話を付け加えると、筆者自身は、過去にお客様向けに構築したインターネットファイアウォールで、IP Options付きIPv4パケットをデフォルトで遮断する設計を採用した経験があります。その後、IP Optionsをインターネット境界で遮断したことによって業務上の問題が発生したり、IP Optionsを許可する設計に変更する必要に迫られた経験はありません。これはあくまで筆者個人の一例ですが、インターネット境界での遮断が実運用で大きな問題になりにくいことを示す参考となると考えます。

理想的な根本対策は、各ベンダーから提供されるCVE-2026-98432の修正を含むソフトウェアアップデートの適用です。ただ、すぐに適用することが難しい場合、修正版を適用するまでの暫定的なリスク低減策として「IP Optionsを含むIPv4 TCP通信を遮断する」ことは、インターネット境界であれば、ほとんどの環境で採用可能ではないかと考えています。

以降の第2章から第5章では、この結論に至った根拠を、IPv4の仕様、IP Optionsの種類、セキュリティ上の懸念、フィルタリングに関するRFCの推奨事項の順に説明し、第6章で全体を整理します。

2. IPv4の仕様とIP Options

現在のインターネット通信は、TCP/IP、あるいはInternet Protocol Suiteと総称される通信プロトコル群を基盤としています。その中核となるプロトコルの一つがIPv4（Internet Protocol Version 4）です。

IPv4の基本仕様は1981年に公開されたRFC 791によって規定され、現在もInternet Standard（STD 5）の一部です。

IPv4パケットの先頭には「IPヘッダ」があり、送信元・宛先のIPv4アドレスや、パケットの配送・制御に必要となる各種情報が格納されます。

IPv4ヘッダはIP Optionsを含まない場合20バイトですが、IP Optionsを付加することで最大60バイトまで拡張できます。したがって、IP Optionsに使用できる領域は最大40バイトです。

IP Optionsが一般的な通信で常に利用されることを前提とした機能ではないことを、ネットワーク設計の実務から見てみます。VPNなどのネットワーク設計では、MTU（Maximum Transmission Unit）やMSS（Maximum Segment Size）を考慮する場面があります。MSSは、1つのTCPセグメントに格納できるTCP Payloadの最大サイズを表します。

RFC 791の仕様上、IP Optionsが付加されるとIPv4ヘッダは20バイトから最大60バイトまで拡張されるため、厳密にはIPv4ヘッダが常に20バイトであるとは限りません。一方、一般的なネットワーク設計ではIPv4ヘッダを20バイトとして扱う場面が多くあります。

例えば、EthernetでMTUが1500バイトの場合、一般的なIPv4/TCP通信では、IPv4ヘッダ20バイト、TCPヘッダ20バイトとして、MSSを「1500 - 20 - 20 = 1460バイト」と計算します。

また、例えばNTTフレッツなどの日本のPPPoE接続では、MTU 1454バイト以下、MSS 1414バイト以下と案内される場合があります。これはIPv4ヘッダ20バイト、TCPヘッダ20バイトとして「1454 - 20 - 20 = 1414バイト」と計算した値です。

このことからも、IP OptionsはIPv4の正式な仕様として存在している一方、現在の一般的なIP通信では常に利用されることを前提とした機能ではない、という性格が見えてきます。

なお、本記事で扱う「IP Options」は、IPv4ヘッダに付加されるオプション情報です。TCPヘッダの「TCP Options」（MSSやWindow Scalingの通知などに使用）とは別の仕組みであり、本記事ではTCP Optionsについては扱いません。

3. 1981年に規定されたIP Options

1981年にRFC 791が策定された時点で、すでに複数のIP Optionsが規定されていました。RFC 791で定義された代表的なIP Optionsには次のものがあります。

• Record Route（RR）: パケットが経由したルーターなどのIPv4アドレスを記録します。
  
  
• Source Routing Options（LSRR / SSRR）: 送信元がパケットの経由先を指定する機能です。経路指定の厳密さによって、LSRR（Loose Source and Record Route）とSSRR（Strict Source and Record Route）の2種類があります。
  
  
• Internet Timestamp: パケットを処理したシステムの時刻情報を記録します。

RFC 791の公開後も、後続のRFCによって新たなIP Optionsが追加されています。例えば、本記事の後半で紹介するRouter Alert Optionは、1997年にRFC 2113で規定されました。

4. IP Optionsを利用することによるセキュリティ上の懸念

1981年に策定されたIPv4は広く利用されるようになりましたが、その用途が広がるにつれて、IP Optionsについてもセキュリティ上の懸念が指摘されるようになりました。

2011年には、IPv4の仕様をセキュリティの観点から評価したRFC 6274 “Security Assessment of the Internet Protocol Version 4”が公開されています。基本仕様を規定する「Internet Standard」ではなく「Informational」という位置付けですが、参考情報として本記事でも参照します。

RFC 6274では、多数のIP Optionsが規定されているものの、Router AlertやSecurity Optionsなどを除けば、一般にはトラブルシューティング目的で利用されると説明したうえで、それぞれのOptionについてセキュリティ上の問題を評価しています。

• Record Route Option については、攻撃者がネットワークトポロジを把握するための情報収集に悪用できる可能性があると指摘しています。
  
  
• Source Routing Options（LSRR / SSRR）については、ファイアウォールルールの迂回や、本来到達不能なシステムへパケットを到達させる目的などに悪用される可能性があり、セキュリティ上の問題が正当な用途を上回るとして、RFC 6274は該当するOptionを含むパケットをデフォルトで破棄することを推奨しています。
  
  
• Internet Timestamp Option については、パケットを処理したシステムの時刻の取得、ネットワークトポロジの把握、OSの推定、clock skew（時計のずれ）を利用した物理デバイスのFingerprinting（識別）などに悪用される可能性があります。このためRFC 6274では、デフォルトではTimestamp Optionを無視することが推奨されています。

5. IP Optionsをフィルタリングして問題ないのか

2014年に公開されたRFC 7126 “Recommendations on Filtering of IPv4 Packets Containing IPv4 Options”は、BCP 186（Best Current Practice）として、IP Optionsを含むIPv4パケットのフィルタリングに関する推奨事項と、その運用上・相互接続上の影響をまとめています。

RFC 7126は、IP Optionsがセキュリティ上の問題につながる可能性がある一方、一部のOptionには正当な利用目的もあることを踏まえ、IP Optionsが付いているという理由だけで一律に遮断するのではなく、Optionの種類ごとにセキュリティ上のリスクや運用への影響を考慮して扱うという考え方を示しています。

• Record Route Option は、第4章で挙げたネットワークトポロジの把握に悪用される可能性があることや、すでにインターネット上で広く遮断されていることを踏まえ、ルーターやファイアウォールなどのネットワーク機器ではRecord Route付きパケットをデフォルトで遮断（drop）することを推奨しています。
  
  
• Source Routing Options（LSRRおよびSSRR）は、第4章で挙げたファイアウォールルールの迂回や、本来到達不能なシステムへのアクセス、ネットワークトポロジの調査などに悪用される可能性があります。すでにインターネット上で広く遮断されていることを踏まえ、ルーターやファイアウォールなどのネットワーク機器では、LSRRまたはSSRRを含むパケットをデフォルトで遮断（drop）することを推奨しています。
  
  
• Internet Timestamp Option は、第4章で挙げたとおり、時刻情報の取得やネットワークトポロジの把握、OSや物理デバイスのFingerprintingなどに悪用される可能性があります。また、Timestamp Optionを利用したパケットがインターネット上ですでに広くフィルタリングされていることから、ルーターやファイアウォールなどのネットワーク機器では、Timestamp Optionを含むパケットをデフォルトで遮断（drop）することを推奨しています。

RFC 7126では、上記を含む多くのIP Optionsについてデフォルトでの遮断を推奨しています。一方、許可が必要となる可能性のあるOptionとして、Router Alert（RFC 2113）や、Security Options（RFC 1108）なども検討されています。

このうち、Security Options（RFC 1108）は米国国防総省（DoD）のネットワーク向けに規定された特殊な用途のOptionで、現在はHistoric（歴史的）に分類されています。

一方、Router Alert Optionのように、特定のネットワーク環境で明確なユースケースを持つOptionも存在します。

このRouter Alertについて、2011年にBCP 168（Best Current Practice）として公表されたRFC 6398 “IP Router Alert Considerations and Usage”が、代表的なユースケースと、安全に利用するための運用・セキュリティ上の推奨事項を示しています。

Router Alert Optionの代表的なユースケースには、企業ネットワーク内の音声・映像通信のリソース予約に使われるRSVP (Resource Reservation Protocol)や、IPv4マルチキャストのグループメンバーシップを管理するIGMP (Internet Group Management Protocol)があります。一方、DoS攻撃などのリスクがあるため、オープンなインターネット（Open Internet）をまたいだRouter Alertへの依存は推奨されず、トラフィックや信頼境界を管理できる環境（Controlled Environment）での利用が推奨されています。

以上のように、RFC 7126はIP Optionsを一律に遮断するのではなく、Optionの種類ごとに判断する姿勢を示しています。ただし、許可が必要となる可能性のあるRouter AlertのようなOptionも、利用が推奨されるのは管理された環境に限られ、オープンなインターネットをまたいだ利用は推奨されていません。このため、外部から到達するインターネット境界に限れば、IP Options付きパケットを遮断しても影響を受ける正当な通信は限られると考えられます。

6. 結論に至る検討内容のまとめ

ここまでの内容を整理し、冒頭の結論に至った根拠をまとめます。IP Optionsは、1981年のRFC 791でIPv4の正式な仕様として規定された機能です（第2章）。Record Route、Source Routing、Timestampといった代表的なOptionは、トラブルシューティングなどを目的に作られた古い機能であり（第3章）、トポロジの把握、ファイアウォールルールの迂回、時刻情報や物理デバイスのFingerprintingなどに悪用され得るというセキュリティ上の懸念が、RFC 6274で指摘されています（第4章）。これを受けてRFC 7126は、これらのIP Optionsをネットワーク機器でデフォルトで遮断することを推奨する一方、Router Alertのように管理された環境で明確なユースケースを持つOptionもあるとして、Optionの種類ごとに判断する姿勢を示しています（第5章）。したがって、インターネット境界で外部から到達するIP Options付きIPv4 TCPパケットを暫定的に遮断するという第1章の結論は、RFCの考え方と整合すると考えられます。一方で、組織内部のネットワークなどIP Optionsが業務上の正当な必要のために利用されている可能性のある環境では、事前の確認が必要です。

なお、ここまで検討した「IP Options付きIPv4 TCP通信を遮断」はあくまでも暫定的な緩和策でしかなく、最終的に実施するべき根本対策は、各ベンダーから提供されるCVE-2026-98432の修正を含むソフトウェアアップデートの適用である、という点は最後に強調しておきます。

参考資料・参照先

RFC / IETF関連

RFC 791: STD 5 (1981年9月): Internet Protocol
IPv4の基本仕様。IP Optionsを含むIPv4ヘッダの形式などを規定しています。
https://www.rfc-editor.org/info/rfc791/

RFC 6274 (2011年7月): Security Assessment of the Internet Protocol Version 4
基本仕様が定められてから約30年経過した時点で、IPv4の仕様や一般的な実装をセキュリティの観点から改めて評価した結果を記したInformational RFCです。
https://www.rfc-editor.org/info/rfc6274/

RFC 7126: BCP 186 (2014年2月): Recommendations on Filtering of IPv4 Packets Containing IPv4 Options
IP Optionsを含むパケットのフィルタリングについて、Optionごとの推奨や遮断による影響をまとめたBest Current Practiceです。
https://www.rfc-editor.org/info/rfc7126/

RFC 2113 (1997年2月): IP Router Alert Option
IPv4のRouter Alert Optionを規定したRFCです。
https://www.rfc-editor.org/info/rfc2113/

RFC 6398: BCP 168 (2011年10月): IP Router Alert Considerations and Usage
Router Alert Optionの利用に関する運用・セキュリティ上の考慮事項をまとめたBest Current Practiceです。
https://www.rfc-editor.org/info/rfc6398/

RFC 1108 (1991年11月): U.S. Department of Defense Security Options for the Internet Protocol
米国国防総省（DoD）の共用データネットワーク向けのOptionを規定したRFCです。現在はHistoric（歴史的）と分類されています。
https://www.rfc-editor.org/info/rfc1108/

CVE-2026-98432 / ベンダー情報

Red Hat : CVE-2026-98432
(2026年10月15日公開、参照時点での最終更新2026年11月2日)
Red HatによるCVE情報。Critical / CVSS v3 9.8として評価されています。
https://access.redhat.com/security/cve/cve-2026-98432

Red Hat Security Bulletin RHSB-2026-016: Use-after-free - kernel IPv4 (CVE-2026-98432)
(2026年10月14日公開、参照時点での最終更新2026年11月4日)
Red Hatによるセキュリティ勧告。IP Optionsを含む受信IPv4 TCPパケットをフィルタリングする暫定緩和策の説明が含まれます。
https://access.redhat.com/security/vulnerabilities/RHSB-2026-016

Ubuntu: CVE-2026-98432
(2026年10月15日公開、参照時点での最終更新2026年11月9日)
UbuntuによるCVE情報。Critical / CVSS 3.1 9.8として評価されており、IP Optionsを含む受信IPv4 TCPパケットを遮断する緩和策の説明が含まれます。
https://ubuntu.com/security/CVE-2026-98432

Ubuntu: Fixes available in -proposed pocket for CVE-2026-98432
(2026年11月2日公開)
UbuntuによるCVE-2026-98432の解説記事です。
https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432

株式会社ソリトンシステムズ: Linuxカーネルの脆弱性 (CVE-2026-98432)に関するお知らせ
(2026年11月2日公開)
弊社ソリトンシステムズ製品におけるCVE-2026-98432対策案内です。
https://www.soliton.co.jp/support/2026/006953.html