メインコンテンツへスキップ
見出し画像

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

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

    (English Version Here.)

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

    【新着記事】
    News #12「CRAの72時間通知、脆弱性の「発生日時」を出せますか｜SRP Glossaryが版番号1.3のまま改訂、利用者への通知義務も確認」を公開しました。
    SRPの入力項目一覧（Glossary）が、版番号 Version 1.3 のまま改訂され、積極的に悪用されている脆弱性の72時間通知で「発生日時」が必須とされました。SRPへの報告とは別に、CRA第14条(8)が製造者に求める利用者への通知も、条文から整理しています。
    → 記事を読む

    【新着記事】
    News #11「MQTTの脆弱性、自社製品は対象か｜CVE-2026-87121（CVSS 9.8）と6LoWPANのCVE-2026-91018」を公開しました。
    米CISAが公表したlwIPの脆弱性2件を、ソースコードとベンダーSDKの照合結果とあわせて整理しました。関係する機能は限られること、示された修正コミットと実際に取り込むべき変更がずれていること、正式リリースがまだないことの3点が判断の要です。
    → 記事を読む

    【新着記事】
    News #10「CRA SRPの利用規約が公開｜稼働後に変わった公式文書4点と参照版の記録」を公開しました。
    報告義務が始まったあとも、ENISAのSRP関連文書は数日単位で変わり続けています。新しく公開された利用規約はSRPへのセキュリティテストにENISAの事前同意を求めており、入力項目を一覧化したGlossaryは5日で2版進んで、どの段階で何が必須かが変わりました。News #9で挙げた項目の訂正を含めて4点を整理しています。
    → 記事を読む

    【新着記事】
    News #9「SRPが表示する72時間の期限は信じてよいか｜9月11日の開始にあたり確認する4点」を公開しました。
    CRAの報告義務の開始日は2026年9月11日です。ENISAが開始直前に更新した3文書を原文で確認したところ、SRPが画面に出す72時間の期限が、認知から72時間になる前に期限超過として表示される場合があるとENISA自身が書いていました。手順へ落としておきたい4点を整理しています。
    → 記事を読む

    はじめまして。組み込み機器の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トラブル対策室｜日本語記事一覧

     
     

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

     
     
    猫とお酒とギター大好きな組み込みエンジニアです。 lwIPの不具合解析や、ネットワークトラブル対策を実務ベースで共有しています。世の中のネットワーク機器の不具合を少しでも減らしていければと思っています。

    あなたへのおすすめ