見出し画像

【lwIP】News #3｜upstream lwIPだけ見ていては気づけないCVE｜ESP-IDF独自DHCPサーバーの境界チェック欠落（CVE-2026-45160）

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

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

本記事は「News」として、lwIPに関する速報・重要な動向をお届けします。News記事は、基本的に外部で公表された情報の整理・注意喚起が中心です。今回は、公開情報の整理に加えて、実際の該当ソースコードを入手して差分を確認した内容も含みます。

■ 今回のニュース概要

Espressif の ESP-IDF に同梱されている lwIP コンポーネントの DHCPサーバー実装に、Out-of-Bounds Read（境界外読み取り、CWE-125）の脆弱性が公開されました。CVE-2026-45160 として登録されています。

  • 対象：ESP-IDF 5.2.7 / 5.3.5 / 5.4.4 / 5.5.4 / 6.0.1

  • 修正版：ESP-IDF 5.2.8 / 5.3.6 / 5.4.5 / 5.5.5 / 6.0.2

  • 該当ファイル：components/lwip/apps/dhcpserver/dhcpserver.c

  • 該当関数：parse_options()

  • 公式アドバイザリ：GHSA-g764-gwc3-75m5「Out-of-bounds Read in lwIP DHCP Server Option Parser」

  • 深刻度：CVSS 3.1 Base Score 6.5（Medium）、ベクタ AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H（GitHub Advisory 由来の値。NVD掲載）

ベクタを読み解くと、次のような性質の脆弱性です。

  • AV:A（Adjacent）：攻撃元は隣接ネットワーク。ESP32等がSoftAP（アクセスポイント）やローカルネットワーク上のDHCPサーバーとして動作している場合、そのネットワークに参加できる相手が対象になります。

  • PR:N / UI:N：認証も、利用者の操作も不要。DHCPリクエストを送るだけです。

  • C:N / I:N / A:H：情報漏洩・改ざんの影響評価は None ですが、可用性（Availability）への影響は High です。つまり、想定される主な影響は機器のクラッシュ・停止（DoS）方向です。

なお、本記事執筆時点で、この脆弱性が実際に悪用された（積極的に攻撃に使われた）という情報は確認できていません。

■ この記事のポイント：なぜ「upstream lwIPだけ」を見ていると見落とすのか

この脆弱性でいちばん重要なのは、深刻度そのものよりも「どこにあるコードか」です。

upstream lwIP（開発元がSavannahで公式に配布・管理しているオリジナルのソース。ベンダーが手を加える前の本家）には、DHCP のクライアント実装（src/core/ipv4/dhcp.c）は含まれていますが、DHCP のサーバー実装は含まれていません。手元の lwIP 2.2.1 のソースツリーを確認しても、DHCPサーバーに相当する dhcpserver.c は存在せず、apps/ 配下にあるのは HTTP・SNMP・MQTT・SMTP・SNTP などで、DHCPサーバーはありません。

一方、ESP-IDF は lwIP のコンポーネントとして、独自の DHCPサーバー実装（dhcpserver.c）を同梱・保守しています。今回の CVE-2026-45160 は、この ESP-IDF 側で追加・保守されているコードに存在するもので、upstream lwIP本体には対応するコードがありません。

ここから導かれる実務上の教訓は明確です。

  • 「lwIP本家のCVE・コミットだけを監視している」運用では、この種のSDK固有の脆弱性は原理的に捕捉できない。

  • 自社が使っているのが「upstream lwIPそのもの」なのか「ベンダーSDKが独自改変・独自追加したlwIP」なのかで、監視すべき情報源が変わる。

これは、以前 News #2 で触れた「ベンダーforkの改変は、upstreamの情報だけでは影響有無を断定できない」という論点の、具体的な実例と言えます。各ベンダーSDKが upstream をどのようにfork・独自追加しているか、どのlwIP版を積んでいるかは、まとめ記事（lwIPのよくある不具合と対策）のベンダー別一覧でも整理しています。

■ ソースコードで確認できたこと

本記事では、実際に該当コードを入手して確認しました。ESP-IDF の脆弱なバージョン（v5.5.4）と修正版（v5.5.5）の dhcpserver.c を取得し、parse_options() 関数の差分を照合しています。

脆弱なバージョンのオプション解析ループ

受信したDHCPメッセージのオプション領域を走査するループは、脆弱なバージョンでは次のような構造でした（DHCPデバッグログや一部の分岐は省略しています）。

static u8_t parse_options(dhcps_t *dhcps, u8_t *optptr, s16_t len)
{
    ...
    u8_t *end = optptr + len;
    u16_t type = 0;

    while (optptr < end) {
        switch ((s16_t) *optptr) {

            case DHCP_OPTION_MSG_TYPE:  //53
                type = *(optptr + 2);
                break;

            case DHCP_OPTION_REQ_IPADDR:  //50
                if (memcmp((char *) &client.addr, (char *) optptr + 2, 4) == 0) {
                    s.state = DHCPS_STATE_ACK;
                } else {
                    s.state = DHCPS_STATE_NAK;
                }
                break;

            case DHCP_OPTION_END:
                is_dhcp_parse_end = true;
                break;
        }

        if (is_dhcp_parse_end) {
            break;
        }

        optptr += optptr[1] + 2;
    }
    ...
}

DHCPのオプション領域は「コード（1バイト）＋長さ（1バイト）＋値（長さバイト分）」が並んだ可変長の構造です。この可変長データを、送信側（＝DHCPリクエストを送ってくる相手）が自由に組み立てられる、という点が前提になります。

上のループには、次の境界チェックが欠けています。

  • type = *(optptr + 2); は、optptr + 2 が受信データの終端 end を超えていないかを確認せずに読み取っています。オプションがオプション領域の末尾近くに置かれていると、optptr + 2 が受信バッファの外を指し得ます。

  • memcmp(..., (char *) optptr + 2, 4) も同様に、optptr + 2 から4バイトを、終端チェックなしで読み取ります。

  • ループ末尾の optptr += optptr[1] + 2; は、長さバイト optptr[1] を読んで次のオプションへ進みますが、この長さの値が受信データ内に収まっているかを検証していません。

結果として、悪意のあるDHCPリクエストを送ることで、parse_options() が受信バッファの外側（隣接するヒープ領域）を読み取ってしまう、というのが今回のOut-of-Bounds Readです。NVDの説明（原文は英語）でも、各オプションの長さバイトと宣言された値の長さが受信パケットバッファ内に収まっているかを検証していない、という趣旨が述べられています。

修正版で追加された境界チェック

修正版（v5.5.5）の parse_options() では、switch分岐に入る前に、各オプションが受信データ内に収まっているかを検証するチェックが追加されています。差分から、追加された要点は次のとおりです。

/* 修正版で追加された境界チェック（抜粋） */
if (*optptr == DHCP_OPTION_PAD) {   // パディング(0)を読み飛ばす
    optptr++;
    continue;
}
if (*optptr == DHCP_OPTION_END) {   // 終端(255)で抜ける
    break;
}
if (optptr + 1 >= end) {            // 長さバイトが範囲内か
    break;
}

u8_t opt_len = optptr[1];

if (optptr + 2 + opt_len > end) {   // 値まで含めて範囲内か
    break;
}

そのうえで、個々のオプション処理でも「メッセージタイプは長さ1以上あるか」「要求IPアドレスは長さ4以上あるか」を確認してから値を読むようになり、末尾のポインタ前進も optptr += opt_len + 2; と、検証済みの長さを使う形に変わっています。要するに、「読む前に、その分だけ受信データが本当にあるかを毎回確かめる」という、境界チェックの追加が修正の中心です。

なお、修正コミットには、この境界チェックのほかに、受信パケット長の上限確認や、パケットコピー処理を pbuf_copy_partial() に置き換える変更、DHCPINFORM対応の機能追加など、複数の変更がまとめて含まれています。セキュリティ上の要点は、上記のオプション長の検証です。

■ 影響を受ける条件

自分の製品が該当するかどうかは、おおむね次の条件で切り分けられます。

  • ESP-IDF を使用しており、そのバージョンが 5.2.7 / 5.3.5 / 5.4.4 / 5.5.4 / 6.0.1 のいずれか（またはこれらを含む系列で修正版未満）である。

  • 機器が DHCPサーバーとして動作している。典型的には、ESP32等を SoftAP（アクセスポイント）として動かし、接続してきた端末にIPアドレスを配る構成です。純粋にDHCPクライアント（親のルータからIPをもらうだけ）としてのみ動作している場合、この dhcpserver.c は経路に入りません。

  • そのDHCPサーバーに、攻撃者が到達できるネットワーク位置にいる（SoftAPに接続できる、あるいは同一ローカルネットワークにいる）。

逆に言えば、「ESP-IDFを使っているが、SoftAP等のDHCPサーバー機能は無効」という構成であれば、この脆弱性の対象外と判断できます。まずは自社製品がDHCPサーバーとして動いているかを確認するのが、影響判定の第一歩です。

■ 確認しておきたいポイント

  • 使用中の ESP-IDF のバージョン（idf.py --version やビルド設定で確認）。対象バージョンに該当しないか。

  • 製品が SoftAP モードやDHCPサーバー機能を使っているか（使っていなければ影響しません）。

  • ESP-IDF を修正版（5.2.8 / 5.3.6 / 5.4.5 / 5.5.5 / 6.0.2 以降）へ更新できるか。更新できない事情がある場合は、Espressif公式の修正差分を確認したうえで、dhcpserver.c の parse_options() 周辺の境界チェックをバックポートできるか（本記事の抜粋コードだけを見て独自に修正しない）。

  • 自社の脆弱性監視の対象に、upstream lwIPだけでなく、使用しているベンダーSDK（今回はESP-IDF）のセキュリティ情報が含まれているか。ここが今回いちばんの確認ポイントです。

■ 公式対応状況・要確認事項

  • 修正状況： ESP-IDF の 5.2.8 / 5.3.6 / 5.4.5 / 5.5.5 / 6.0.2 で修正されています。upstream lwIPには対応するDHCPサーバー実装が無いため、この件は「upstream lwIPの修正待ち」ではなく、ESP-IDF側の更新で対応するものです。

  • 深刻度： NVDページでは、GitHub Advisory 由来の CVSS 3.1 Base Score 6.5（Medium）、可用性影響 High が確認できます（NVD）。NIST独自の再評価は本記事執筆時点では付与されていません。

  • 悪用状況： 本記事執筆時点で、実際の悪用や、CRA（サイバーレジリエンス法）上の報告対象になったという情報は確認できていません。この点は今後の情報を要確認とします。

  • 一次情報： 詳細は NVD の CVE-2026-45160 ページ、および Espressif の個別アドバイザリ GHSA-g764-gwc3-75m5「Out-of-bounds Read in lwIP DHCP Server Option Parser」で確認してください。

■ CRA時代の監視という観点で

CVE-2026-45160 自体は、現時点で悪用実績が確認されているわけではなく、深刻度も Medium です。それでもNews記事として取り上げるのは、これが「SDKごとに脆弱性を監視する必要がある」ことの分かりやすい実例だからです。

CRAの報告義務（News #2参照）に備える場合、「自社製品が、どのSDKの、どのバージョンのlwIPを、どの機能を有効にして使っているか」を事前に把握できているかどうかで、いざ脆弱性が出たときの初動が変わります。upstream lwIPだけを見ていると、今回のようなSDK固有の実装は監視網から漏れます。

この「どのSDKに、どのCVEが、どの条件で影響するか」を1枚に整理していく取り組みとして、本シリーズでは主要ベンダーSDK（STM32Cube / NXP MCUXpresso / ESP-IDF / TI MCU+ など）別のCVE影響整理を継続して育てています。今回のESP-IDF DHCPサーバーの件は、その「ESP-IDF固有・upstreamに無い」列の具体例として記録に加わります。

■ 本記事の取り扱いについて（免責事項）

  • 目的： 本記事は、公開されている脆弱性情報と公開ソースコードをもとに、lwIP関連の動向を整理し、利用者の注意喚起・確認ポイントの整理を目的としています。

  • 検証： 本記事の技術的な記述は、NVD等の公開情報と、ESP-IDF の公開ソースコード（v5.5.4 と v5.5.5 の dhcpserver.c）の差分確認に基づくものです。実機での再現・検証は行っていません。

  • 自己責任： 修正の適用や対応の判断にあたっては、各プロジェクトの要件に基づき、利用者自身の責任において十分な検証を行ってください。

  • 免責： 万一、本記事の情報に基づいて生じた損害やトラブルについて、筆者は一切の責任を負いかねます。

■ 最後に

今回は、ESP-IDF の lwIP コンポーネントに含まれるDHCPサーバー実装のOut-of-Bounds Read（CVE-2026-45160）について、公開情報と実際のソースコード差分をもとに整理しました。深刻度そのものより、「upstream lwIPには無い、SDK固有のコードに存在する脆弱性」であるという点が、監視・影響判定の観点で重要です。

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

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

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

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

  • 原因特定の時間短縮

  • 対応コストの低減

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

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

関連記事・新着のお知らせ

lwIPの不具合・脆弱性の記事は、症状ごとに継続して追加しています。自社が使っている機能に関わる脆弱性が出たときに気づけるよう、下のマガジンをフォロー・ブックマークしておくことをおすすめします。

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