見出し画像

【lwIP】Common Bugs, Vulnerabilities and Fixes | Embedded Engineer's Field Notes

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

Japanese version available here: 日本語版

This series covers real-world bugs, vulnerabilities, reproduction steps, minimal fixes, and debugging know-how for lwIP — the TCP/IP stack widely used in embedded systems.
▶ English articles index: lwIP Troubleshooting Notes

[New Article]
Bug #4: "PCB Held for 38 Minutes After lwip_close() | The Missing FIN_WAIT_1 Timeout" is now available.
After calling lwip_close(), a TCP PCB can remain occupied for up to 38 minutes due to a missing FIN_WAIT_1 timeout — source code analysis and a minimal patch candidate included.
→ Read the article

[New Article]
News #1: "13 Reported Vulnerabilities? | SMTP Buffer Overflow" is now available.
A look at one disclosed finding from a reported 2026 lwIP security audit: an SMTP client tx_buf buffer overflow (Savannah Bug #68313), reviewed against the public source code.
→ Read the article

[New Article]
Tips #2: "How to Decrypt TLS 1.3 Traffic with Wireshark — mbedTLS 3.x/4.x" is now available.
Step-by-step guide to decrypting TLS 1.3 traffic in Wireshark with mbedTLS 3.x/4.x, including a case study of an mbedTLS 3.1.0-specific bug.
→ Read the article

Hi. I'm an embedded systems engineer who specializes in diagnosing TCP/IP issues in lwIP-based products.

Over years of development, I've repeatedly run into problems like:

  • Unexplained communication hangs

  • Hard-to-reproduce crashes

  • Bugs that leave no trace in the logs

These are the kinds of issues that eat days of investigation time — and most of them have known root causes buried in lwIP's source code.

■ What is lwIP?

lwIP (lightweight IP) is an open-source TCP/IP stack designed for embedded systems. Its low memory footprint makes it a popular choice across a wide range of microcontroller platforms.

It's integrated into SDKs from STMicro (STM32), NXP (i​.MX RT), Renesas (RX/RA/RZ), TI (Sitara), and AMD (Zynq), among others. But with wide adoption comes a hidden risk: many products ship with old lwIP versions that contain known bugs — bugs that only surface under specific conditions like stress tests or security audits.

Network-related issues in particular tend to appear only under conditions such as:

  • High-load stress testing

  • Security/penetration testing

  • Specific packet sequences or timing

This makes them easy to miss in standard functional testing, and hard to diagnose once they appear in the field.

■ What This Series Covers

For each issue, this series provides:

  • Symptom — what you observe when the bug occurs

  • Reproduction — steps to trigger it reliably

  • Root cause — what's happening inside lwIP

  • Fix — configuration change or minimal patch

All analysis is based on publicly available lwIP source code and verified on actual hardware.

■ Why Publish This?

lwIP is free, widely adopted, and ships inside most vendor SDKs. But that convenience comes with trade-offs:

  • Vendor SDKs often bundle outdated lwIP versions

  • Fixes merged into upstream lwIP may never make it into your SDK

  • Upgrading lwIP in a shipped product is rarely straightforward

For products already in the field, a simple "update to the latest version" isn't always an option due to:

  • Regression test costs

  • Unclear impact scope

  • No budget allocated for post-shipment fixes

This is where targeted, minimal patches become valuable.

A note on "upstream lwIP": Throughout this series, "upstream lwIP" refers to the official source maintained at Savannah (nongnu.org), the original, before any vendor modifications. SDK-bundled versions (NXP MCUXpresso, AMD Vitis, etc.) are vendor forks that may diverge significantly from upstream. A bug fixed in upstream may still be present in your SDK's bundled version. Vendors may also add components that do not exist in upstream at all. For example, an out-of-bounds read (CVE-2026-45160) was found in ESP-IDF's own DHCP server implementation, which is not part of upstream lwIP; monitoring only upstream lwIP would miss such fork-specific issues.

Here's a snapshot of lwIP versions found in major vendor SDKs at the time of writing:

STMicroelectronics (STM32Cube)

  • Generally ships upstream lwIP (not a fork)

  • STM32CubeF1/F2: lwIP 2.0.3

  • STM32CubeF4/F7: lwIP 2.1.2

  • STM32CubeH7: lwIP 2.2.1

NXP (MCUXpresso SDK)

  • Maintains its own fork with modifications to the core

  • LPC17xx/LPC40xx: lwIP 1.4.1

  • LPC54xxx / i​.MX RT: lwIP 2.2.1 (NXP fork)

Renesas (RX / RA / RZ)

  • Generally ships upstream lwIP

  • RX series: lwIP 2.2.1
    (Note: Renesas's proprietary M3S-T4-Tiny TCP/IP stack reached end-of-support in December 2025; lwIP is now the official recommended replacement.)

  • RA series: lwIP 2.2.0 (bundled with FSP)

  • RZ/N2H: lwIP 2.2.0 pre-release snapshot

TI (Sitara / MCU+ SDK)

  • Generally ships upstream lwIP

  • AM243x: lwIP 2.2.0

  • TM4C123/129 (TivaWare): lwIP 1.4.1

AMD / Xilinx (Vitis SDK)

  • Core is nearly identical to upstream; minor extensions added

  • lwIP 2.2.0

Espressif (ESP-IDF / ESP32)

  • Uses its own fork (esp-lwip) based on upstream lwIP, with components added that do not exist in upstream (such as a DHCP server)

  • ESP-IDF 5.4 and later (including 6.0): esp-lwip (based on lwIP 2.2.0)

  • ESP-IDF 5.0 to 5.3: esp-lwip (based on lwIP 2.1.3)

  • An out-of-bounds read (CVE-2026-45160) in this added DHCP server is one example of a fork-specific vulnerability

Versions shown above are representative examples confirmed at the time of writing. The actual version in your project may differ depending on your SDK release and target board.

■ Why This Matters Now

lwIP bugs are no longer just a reliability concern — security regulations are making vulnerability management a compliance requirement.

EU Cyber Resilience Act (CRA)

Enacted in 2024 and in effect from December 2024, the EU CRA requires manufacturers of network-connected products to manage cybersecurity across the product lifecycle. This explicitly includes known vulnerabilities in bundled open-source components like lwIP.

The reporting side is now becoming concrete. ENISA (the EU Agency for Cybersecurity) has announced that the Single Reporting Platform (SRP), used for CRA vulnerability and severe-incident reporting, is scheduled to go live on 11 September 2026 (the reporting obligations start the same day). The deadlines, counted from becoming aware, are: an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days after a corrective measure is available (for severe incidents, within one month of the initial notification). (Source: ENISA SRP FAQ; details to be confirmed.)

This creates a practical problem for embedded products. If your process is to "start investigating only after a vulnerability is detected," you may not make the 72-hour deadline. You cannot judge impact quickly unless you already know, in advance, which lwIP version you ship, whether it is a vendor fork, which features you enable (SNMP, DHCP, DNS, etc.), and whether the flaw is reachable from outside. The Bug Series in this collection organizes exactly that (which conditions, which versions, and which features are affected) at the source-code level, per symptom.

SBOM Requirements

Software Bills of Materials (SBOMs) — inventories of software components and their versions — are increasingly required by customers and regulators in the US and EU. Knowing exactly which lwIP version you ship, and which CVEs apply, is a basic SBOM requirement.

What Engineers Are Facing

In practice, this means:

  • Security audits now ask: "Are known CVEs in your OSS components addressed?"

  • Customers and partners request documented vulnerability response status

  • Internal reviews require engineers to explain impact and mitigation plans

Understanding lwIP bugs at the source-code level — knowing which conditions trigger them and how to apply a minimal fix — is increasingly part of the job, not just optional deep knowledge.

■ Article Index

Articles published so far (more to come):

News Series

Short updates on notable lwIP-related news, such as security audits, CVE registrations, and new releases.
These articles summarize and highlight information already published externally.

Tips Series

Tips articles cover debugging techniques and development know-how for lwIP-based products.
This includes related libraries such as mbedTLS, which is commonly used alongside lwIP.

Bug Series

Each article covers a real-world bug or vulnerability found in lwIP.
Reproduction steps, source-level root cause analysis, and minimal patches are included.

■ How Bug Series Articles Are Structured

Bug Series articles (paid) follow this structure:

  • Free section: symptom, trigger conditions, problem overview (including where the root cause lies)

  • Paid section: reproduction steps, source code analysis, fix method, post-fix verification, official fix status

The paid section includes source-code-level analysis and a minimal patch candidate designed to limit the scope of change — practical for teams that cannot do a full version upgrade.

■ Closing Note

lwIP is free and easy to integrate into products, but using it responsibly requires understanding the version in use, its configuration, and known issues.
As an OSS project without commercial support guarantees, the product manufacturer ultimately bears the responsibility for handling bugs and vulnerabilities.
The risk of support costs escalating after product shipment is something worth planning for in advance.

lwIP offers many advantages as an open-source stack, but for products where long-term maintenance and formal support are critical, a commercial TCP/IP stack may be the right choice.

That said, replacing lwIP in a product already in development or already shipped is rarely practical.
For those engineers, this article's information may be useful for:

  • Early detection of bugs and vulnerabilities

  • Reducing root cause investigation time

  • Lowering the cost of remediation

More articles coming. Stay tuned.

▶ English article index: lwIP Troubleshooting Notes

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