見出し画像

【lwIP】よくある不具合と対策まとめ｜組み込みTCP/IPトラブル事例集

lwIPトラブル対策室(lwIP Lab)

(English Version Here.)

このnoteでは、lwIPで実際に起こり得る不具合・脆弱性・再現方法・最小修正の考え方やデバッグのノウハウをシリーズで解説しています。
▶ 日本語記事一覧はこちら：lwIPトラブル対策室｜日本語記事一覧

News #6「CRAの脆弱性報告、9月11日開始｜SRP運用ガイドが示した6つの実務ポイント」を公開しました。
ENISAがSRPの登録・通知提出・画面機能のガイダンスを公開しました。下書きは担当者間で共有されない、事前登録は推奨されない、CVE公開だけでは報告義務は発生しないなど、実務で誤解しやすい6点を一次情報から整理しています。
→ 記事を読む

【新着記事】
News #5「lwIPの脆弱性に気づけるのはいつか｜GitHub・Savannah・CVE・ベンダーSDKで情報が出る時期はずれている」を公開しました。
実際に追跡した2件を対比し、CVEが出る件と出ない件があること、修正が upstream lwIP のmasterに入っても正式リリースには反映されないことを整理しています。ベンダーSDKが同梱するlwIPは1.4.1から2.2.1まで開きがあります。
→ 記事を読む

【新着記事】
News #4「lwIPの脆弱性、責任を負うのは誰か｜CRA正式ガイダンス公開が示す「製造者責任」」を公開しました。
欧州委員会がCRA適用ガイダンスを正式公開。lwIPがOSSでも、完成品をEU市場に出す製造者が脆弱性の影響判定・報告の責任を負うという「製造者責任」の考え方を、一次情報をもとに整理しています。
→ 記事を読む

【新着記事】
News #3「upstream lwIPだけ見ていては気づけないCVE｜ESP-IDF独自DHCPサーバーの境界チェック欠落（CVE-2026-45160）」を公開しました。
ESP-IDFが独自に同梱するlwIPのDHCPサーバー実装に見つかったOut-of-Bounds Read（CVE-2026-45160）。upstream lwIPだけを監視していると見落とす、SDK固有の脆弱性です。
→ 記事を読む

はじめまして。組み込み機器のTCP/IP通信不具合（主にlwIP）を調査・解析しているエンジニアです。

これまでlwIPを使用した開発中に、

  • 原因不明の通信停止

  • 再現が難しいクラッシュ

  • ログに残らない不具合

といった、「調査に多くの時間がかかる問題」に直面した経験はないでしょうか。

■ lwIPとは

lwIP（lightweight IP）は、組み込みシステム向けに設計されたオープンソース（OSS）のTCP/IPスタックです。
少ないメモリ資源でも動作することから、多くのマイコン環境で採用されています。

組み込み機器では、STMicro STM32、NXP i​.MX RT、Renesas RA、TI Sitara、AMD Zynq などを中心に、lwIPが広く利用されています。
その一方で、特定条件でのみ発生する不具合や、既知の問題が見過ごされたまま使われているケースも少なくありません。

特にネットワーク処理は、

  • 負荷試験時

  • セキュリティ試験時

  • 特定の通信シーケンス

といった条件でのみ問題が顕在化することがあります。

そのため、通常の動作確認では問題が見えにくく、原因特定に時間を要することが多い分野です。

■ このnoteでやること

このnoteでは、lwIPを利用した製品で遭遇しやすい問題について、

  • 症状（どのような現象が発生するか）

  • 再現方法（実際に確認できる手順）

  • 原因（lwIP内部の挙動）

  • 対策（設定変更・修正方法）

を整理して公開します。

※内容は公開されたlwIPソースコードおよび検証環境に基づいています。

■ なぜこの情報を公開するのか

lwIPはオープンソースのTCP/IPスタックとして多くのマイコンベンダーが提供するSDKに無償で提供されており、手軽にネットワーク機能を実装できる一方で

  • lwIPバージョンが古いままアップデートされていない

  • 最新版では修正されている既知の問題が修正されていない

  • アップデートに伴う変更への対応が難しい

といった理由から、問題を抱えたまま使われるケースがあります。

特に出荷済み製品では、

  • 試験コストの増大

  • 影響範囲の不透明さ

  • 対応費用が予算に含まれない

といった理由により、単純なアップデートが難しい場合もあります。

また、lwIPは産業機器や量産組み込み製品で採用例の多い各種マイコンベンダーSDKへ統合されていますが、各社で運用方針や改変内容には大きな違いがあります。

ここで、本記事で頻繁に使用する「upstream lwIP」という用語について説明します。

upstream lwIPとは、lwIPの開発元（Savannah / nongnu.org）が公式に配布・管理しているオリジナルのソースコードを指します。ベンダーが手を加える前の、開発元オリジナルのlwIPです。
一方、NXP MCUXpresso SDK、AMD Vitis SDKなどに含まれるlwIPは、各ベンダーが upstream をベースに独自のパッチや設定変更を加えた「ベンダーfork」です。さらに、ベンダーが upstream には無い独自コンポーネントを追加している場合もあります。そのため、upstream で修正されたバグがベンダーforkに反映されていなかったり、逆にベンダー独自の問題が含まれていたりするケースがあります。実際に、ESP-IDFが upstream には無い独自のDHCPサーバー実装で見つかったOut-of-Bounds Read（CVE-2026-45160）を、News #3で扱っています。upstream lwIPだけを監視していると、こうしたfork固有の問題は見落とされます。

例えば：

  • STMicroelectronics（STM32Cube系）

    • 独自forkではなく、upstream版が使われているケースが多い

    • STM32CubeF1/F2： lwIP 2.0.3 を使用

    • STM32CubeF4/F7： lwIP 2.1.2 を使用

    • STM32CubeH7： lwIP 2.2.1 を使用

  • NXP（MCUXpresso SDK、LPCOpen系）

    • upstream版ではなくNXP独自forkをベースにしており、コアにも手が加えられている

    • LPC17xx/LPC40xx系： lwIP 1.4.1 を使用

    • LPC54xxx系、i​.MX RT系： lwIP 2.2.1 NXP fork を使用

  • Renesas（RX、RA、RZ系など）

    • 独自forkではなく、upstream版が使われているケースが多い

    • RX系： lwIP 2.2.1 を使用
      ※従来は Renesas 独自の TCP/IP スタック M3S-T4-Tiny が使われていたが、2025年12月にサポート終了となり、現在は lwIP が公式後継として推奨されている。

    • RA系： lwIPはFSPにバンドル、lwIP 2.2.0 を使用

    • RZ系： 型番により対応は様々。RZ/N2H では lwIP 2.2.0 正式リリース前のスナップショット版が使用されている。

  • TI（Sitara / TivaWare SDK系）

    • 独自forkではなく、upstream版が使われているケースが多い

    • Sitara (AM243x)： lwIP 2.2.0 を使用

    • TivaWare（TM4C123/129）： lwIP 1.4.1 を使用

  • AMD(旧Xilinx)（Vitis SDK系）

    • lwIPコア本体はほぼ upstream と同一だが、一部独自拡張あり

    • lwIP 2.2.0 を使用

  • Espressif（ESP-IDF / ESP32系）

    • upstream版そのものではなく、upstream lwIP をベースにした独自fork（esp-lwip）を使用しており、upstream には無い独自コンポーネント（DHCPサーバーなど）が追加されている

    • ESP-IDF 5.4以降・6.0系： esp-lwip（lwIP 2.2.0 ベース）を使用

    • ESP-IDF 5.0〜5.3系： esp-lwip（lwIP 2.1.3 ベース）を使用

    • この独自DHCPサーバー実装で見つかった脆弱性（CVE-2026-45160）は News #3 で解説

※上記に記載したバージョンは、本記事執筆時点で確認できた代表例です。実際のバージョンは、使用しているSDKのリリース、対象ボード、サンプルパッケージによって異なる場合があります。

このように、ベンダーや製品シリーズによってlwIPのバージョンは 1.4.x から 2.2.x まで幅広く、実際にはベンダー独自パッチや設定変更が加えられているケースも多いため、単純に upstream の情報だけでは判断できないことがあります。

本記事では、可能な限り

  • upstream lwIPの挙動とバージョン別の差異

  • ベンダーSDKでの実装差異

  • 実際の組み込み製品で起きやすい問題

を分けて解説します。

■ なぜ今、lwIPの問題に向き合う必要があるのか

技術的な問題として見過ごされがちなlwIPの不具合ですが、近年のセキュリティ規制の動向により、既知の脆弱性への対応は任意ではなく、義務として求められる問題になりつつあります。

もちろん、すべての製品に対して即座に最新版へ更新すべき、という単純な話ではありません。重要なのは、まず「自社製品が影響を受ける可能性があるか」を把握し、必要に応じて影響評価・回避策・最小修正を検討できる状態にしておくことです。

セキュリティ規制の動向

EU Cyber Resilience Act（CRA）

2024年に成立し、2024年12月に発効した EU サイバーレジリエンス法（CRA）は、ネットワーク接続機能を持つ製品に対して、製品ライフサイクル全体にわたるサイバーセキュリティ対応を求める規制です。製品に組み込まれた OSSコンポーネントの既知の脆弱性についても、製造者が把握・対応する責任を求めています。

この報告義務を具体化する動きも進んでいます。ENISA（EUサイバーセキュリティ機関）は、CRAの脆弱性・重大インシデント報告に使う Single Reporting Platform（SRP）を2026年9月11日に稼働させる予定を公表しました（報告義務の適用開始も同日）。報告の期限は、認識した時点から24時間以内に早期警告、72時間以内に正式通知、修正・緩和策が利用可能になってから14日以内に最終報告（重大インシデントは初回通知後1か月以内）と定められています。なお、この報告義務の適用開始（2026年9月11日）と、CRAの主要義務の適用開始（2027年12月11日）は別のタイミングです。2026年9月11日にCRAの全要件が課されるわけではなく、まず脆弱性・重大インシデントの報告義務が先行して始まる、という位置づけです。（出典：ENISA SRP FAQ。細目は要確認）

ここで組み込み製品には現実的な問題が生じます。lwIPの脆弱性を「検知してから調査を始める」体制では、72時間の通知期限に間に合わない可能性があります。自社製品が使っているlwIPのバージョン、ベンダーfork、有効にしている機能（SNMP・DHCP・DNSなど）、その脆弱性が外部から到達可能かを事前に把握していなければ、影響有無を短時間で判断できないためです。本シリーズのBug記事は、まさにこの「どの条件で・どのバージョンが・どの機能で影響を受けるか」を、症状ごとにソースコードレベルで整理したものです。

SBOM（ソフトウェア部品表）の管理

OSSを含むソフトウェアコンポーネントを一覧化した SBOM（Software Bill of Materials）の整備が、欧米を中心に製品出荷の要件として広まりつつあります。lwIPのバージョンと既知の脆弱性を把握しておくことは、SBOM管理の基本です。

日本国内の動向

経済産業省が公開している「IoTセキュリティガイドライン」や「サイバーセキュリティ経営ガイドライン」においても、製品に組み込んだOSSの脆弱性管理とPSIRT（製品セキュリティインシデント対応チーム）体制の整備が推奨されています。

担当エンジニアが直面する現実

こうした背景から、開発・品質・セキュリティ担当者が次のような状況に置かれるケースが増えています：

  • セキュリティ試験・脆弱性診断で「OSSの既知CVEに対応しているか」を問われる

  • 顧客や取引先から「使用OSSの脆弱性対応状況を示せ」と要求される

  • 社内セキュリティ審査で「脆弱性を把握した上で対応方針を説明せよ」と求められる

lwIPの不具合や脆弱性をソースコードレベルで把握し、影響範囲と対策を説明できる状態にしておくことは、個人の技術向上だけでなく、製品の品質保証やコンプライアンス対応においても重要な意味を持ちます。

しかし実際の現場では、「最新版へ更新してください」だけでは現実的に解決できないケースも多く、実際には

  • どの条件で問題が発生するのか

  • 自社製品に影響があるのか

  • 最小変更で回避できるのか

  • 出荷済み製品へどう適用するのか

といった「影響有無の分析」や「最小変更での回避策」が求められます。

■ 記事一覧

以下の記事を公開しています：
今後順次追加します。

News シリーズ

lwIP関連の速報・重要な動向を取り上げます。
脆弱性監査結果やCVE登録、新バージョンリリースなど、外部で公表された情報を整理し、注意喚起を行います。

Tips シリーズ

lwIPを使った製品の開発・デバッグに役立つノウハウを扱います。
lwIPと組み合わせて使われる mbedTLS など、周辺ライブラリも取り上げます。

Bug シリーズ

lwIPに存在する不具合・脆弱性を取り上げます。
再現手順・ソースコード解析・最小修正パッチを中心に解説します。

  • 2026-05-17公開
    【lwIP】Bug #1｜accept()でクラッシュする原因｜二重解放バグ
    lwIP 2.1.2 の lwip_accept() に存在する二重解放バグを解説。

  • 2026-05-24公開
    【lwIP】Bug #2｜SYNスキャンで既存TCP接続が切断される原因｜TCP_LISTEN_BACKLOG未設定の落とし穴
    SYNスキャンで確立済みTCP接続が切断される問題。TCP_LISTEN_BACKLOG未設定時のPCBプール枯渇・tcp_kill_prio()の誤動作を解説。

  • 2026-05-31公開
    【lwIP】Bug #3｜DHCPスプーフィングで通信経路を乗っ取られる？｜XID予測を招くLWIP_RAND()の脆弱性
    DHCPトランザクションID（XID）が予測可能になる脆弱性。LWIP_RAND()の実装次第では偽DHCP応答が受理され、ゲートウェイ・DNSを差し替えられる仕組みと対策を解説。（全文無料）

  • 2026-06-21公開
    【lwIP】Bug #4｜lwip_close()後に38分間PCBが解放されない｜FIN_WAIT_1タイムアウト未実装の落とし穴
    lwip_close()後にFIN_WAIT_1専用タイムアウトが存在しないためPCBが最大38分間占有される問題。tcp_slowtmr()の実装を解析し、最小修正パッチ案を解説。

  • 2026-07-12公開
    【lwIP】Bug #5｜切断したはずのRSTが効かず接続が残る｜CVE-2004-0230対策の副作用
    切断用のRSTがチャレンジACK（RFC 5961）機構で受理されず、接続が残ってしまう問題。CVE-2004-0230（TCP RST攻撃）対策として導入されたチャレンジACKの副作用を解析し、対策を解説。

  • 2026-07-20公開
    【lwIP】Bug #6｜SNMP対応機器が1パケットで異常停止（HardFault）する原因｜SNMPv3認証パラメータのスタックバッファオーバーフロー（CVE-2026-8836）
    SNMPv3を有効にしたlwIP 2.1.0〜2.2.1で、認証情報を持たない相手からの1パケットで固定長スタックバッファをはみ出す脆弱性（CVE-2026-8836、CVSS 9.8）。実機でHardFaultによる異常停止を再現し、原因と修正方法を解説。

■ Bug シリーズ記事の構成について

Bug シリーズ各記事（有料記事）は以下の構成を基本としています：

  • 無料パート：現象・発生条件・問題の概要（原因の所在まで）

  • 有料パート：再現手順・ソースコード解析・修正方法・修正後の確認方法・公式対応状況

同様の現象で困っている方、出荷済み製品の修正対応が必要な方に向けて、ソースコードレベルでの原因解析と、すぐに実践できる具体的な修正方法まで解説しています。
また、影響範囲を極力小さくするため、最小限の設定変更や検証済みの修正パッチ案を掲載しています。

■ 最後に

lwIPは無料で手軽に製品に組み込める反面、利用する際にはバージョンや設定、既知の問題を把握しておくことが重要です。
また、商用製品のような保証付きサポートが前提ではないOSSであるため、最終的にはメーカー自身で不具合や脆弱性に対応しなければなりません。
そのため対応コストが製品出荷後に増大するリスクについても考慮しておく必要があります。

OSSであるlwIPには多くの利点がありますが、長期保守やサポート体制が重要な製品では、商用スタックを選択するケースもあります。

ただし、すでにlwIPで開発中の製品や出荷済みの製品を今から置き換えることは現実的ではありません。
そういった方に向けて、本記事の情報が、

  • 不具合や脆弱性の早期発見

  • 原因特定の時間短縮

  • 対応コストの低減

の参考になれば幸いです。

今後も、lwIPの問題に対して実用的な情報を公開します。

▶ 日本語記事一覧はこちら：lwIPトラブル対策室｜日本語記事一覧

いいなと思ったら応援しよう！