見出し画像

【lwIP】News #1 | 13 Reported Vulnerabilities? | SMTP Buffer Overflow

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 article index: lwIP Troubleshooting Notes

This article is part of the News series, covering notable updates and developments related to lwIP. News articles generally focus on summarizing and highlighting information already published externally, rather than bugs or vulnerabilities the author has reproduced or analyzed independently. If a specific vulnerability warrants a closer look, it will be covered separately in a future Bug, Tips, or Guide article.

■ Overview

In 2026, a GitHub repository was published claiming that 13 vulnerabilities were reported as the result of a security audit targeting lwIP.

Of these, one is referenced in the repository as Savannah Bug #68313, and a related fix has been merged into the lwIP upstream `master`. However, as of June 15, 2026, the corresponding Savannah page could not be accessed, so this article limits its scope to what can be confirmed from the public repository and the lwIP upstream source. According to the repository's description, the remaining 12 findings have been "reported to the lwIP maintainers but not yet disclosed."

This article reviews the one finding that is currently disclosed (an SMTP client buffer overflow), based on the publicly available source code. For the remaining 12 findings, no details have been published in this repository, so their content cannot be evaluated.

■ What Was Reported (Structure of the Public Repository)

The repository is organized into one directory per vulnerability, and each directory contains the following:

  • `README.md`: An overview of the vulnerability

  • `setup.sh`: A script for setting up the verification environment

  • `harness/`: A test harness for reproduction

  • `standalone/`: Standalone reproduction code

  • `patch/`: A diff file with a proposed fix

The scope is reported to span a wide range of lwIP, including the SMTP client, the DNS resolver, DHCP, the HTTP/MQTT/SNMP applications, and the core IP stack. However, at the time of writing, the only finding for which details can be confirmed in the xchglabs/lwip-2026-pocs repository is the one that has been disclosed. Other lwIP-related vulnerability information may have been published through different channels, so this article limits its scope to what can be confirmed in this repository.

■ Disclosed Vulnerability: SMTP Client tx_buf Buffer Overflow (Bug #68313)

The one disclosed finding is a buffer overflow in the SMTP client's authentication response handling. In the repository, it is referenced as Savannah Bug #68313.

This article limits its scope to summarizing publicly available information. Proof-of-concept execution steps, detailed reproduction conditions, and notes on applying the patch may be covered separately in a future Bug article if needed.

What We Found in the Source Code

In `src/apps/smtp/smtp.c`, the `smtp_prepare_auth_or_mail()` function copies the `AUTH ...` response line received from the SMTP server into the fixed-length buffer `tx_buf`.

`tx_buf` is defined as follows (`SMTP_TX_BUF_LEN` is 255):

char tx_buf[SMTP_TX_BUF_LEN + 1];

The copy is performed as follows:

u16_t copied = pbuf_copy_partial(s->p, s->tx_buf, (u16_t)(crlf - auth), auth);
s->tx_buf[copied] = 0;

`crlf - auth` is the length from immediately after `AUTH ` (or `AUTH=`) to the CRLF in the received response line — a value sent directly by the server as part of its response. The `tx_buf` array is `SMTP_TX_BUF_LEN + 1` (256) bytes, but because a NUL terminator is written at the end, the maximum length that may be copied is `SMTP_TX_BUF_LEN` (255) bytes. No clamp to this limit is applied before the copy.

lwIP's SMTP client feature (`apps/smtp`) was added in lwIP 2.1.0 and is not present in the earlier 2.0.x series. In the versions we checked, `smtp.c` from 2.1.0 through 2.2.1 all had the same unclamped structure described above.

Impact

  • This applies to configurations that use the SMTP client feature (`apps/smtp`) with `SMTP_SUPPORT_AUTH_PLAIN` or `SMTP_SUPPORT_AUTH_LOGIN` enabled. In the upstream `smtp_opts.h` we checked, these are enabled by default, but you should verify the actual setting in the configuration file of the lwIP version or vendor SDK you are using.

  • In typical usage, the response from the SMTP server that the device connects to is the trigger. If the destination SMTP server is malicious, or if responses can be tampered with on the network path, a longer-than-expected response line could cause a buffer overflow.

  • According to the public repository's writeup, this processing occurs during EHLO response handling, before any SMTP authentication credentials are sent. This means the issue could occur while parsing the AUTH line in the server's response even if the device does not configure SMTP authentication.

Reach Conditions and Impact Described in the Published Article

A blog post by the same author as the xchglabs/lwip-2026-pocs repository (xchglabs.com) provides a more detailed explanation of this issue.

According to this article, the issue occurs while parsing the `AUTH` line (a capability line) in the EHLO response, before any SMTP authentication credentials are sent. Therefore, even if the device does not configure SMTP authentication credentials, the issue could occur if the response from the destination SMTP server contains a long `AUTH` line. The described reach conditions include any SMTP server that the lwIP SMTP client connects to, or a man-in-the-middle on the network path who can tamper with responses. Configurations that use STARTTLS without validating the server certificate are also said to be in scope.

The article also points out that the impact may not be limited to a simple send failure or crash. Following `tx_buf` are a pointer to the received `pbuf`, pointers and lengths for the from address, to address, subject, and body, and a callback function pointer that is called on completion. If these are overwritten, subsequent processing could behave in unexpected ways. The actual impact depends on where `smtp_session` is placed in memory, the memory protection mechanisms of the target environment, build settings, and the surrounding memory layout. This article does not cover proof-of-concept or exploitation details. Instead, it focuses on the impact conditions and fix approach that users should check.

Fix Approach

The repository's proposed fix (`smtp_txbuf_clamp.diff`) is a minimal change that clamps the length to `SMTP_TX_BUF_LEN` before the copy.

u16_t auth_line_len = (u16_t)(crlf - auth);
u16_t safe_len = (auth_line_len < SMTP_TX_BUF_LEN) ? auth_line_len : SMTP_TX_BUF_LEN;
u16_t copied = pbuf_copy_partial(s->p, s->tx_buf, safe_len, auth);

In the lwIP upstream repository, a fix that keeps the copy length within `SMTP_TX_BUF_LEN` was merged into `master` in commit `614420f`, dated May 12, 2026. However, as of June 15, 2026, no new official release tag including this fix has been confirmed. The latest official release tag is 2.2.1, so environments using 2.2.1 as-is would need to consider incorporating the fix separately.

■ Points to Check

  • Whether your lwIP includes `src/apps/smtp/smtp.c` (this issue does not apply if you do not use the SMTP client feature)

  • The settings for `SMTP_SUPPORT_AUTH_PLAIN` / `SMTP_SUPPORT_AUTH_LOGIN` (enabled by default in upstream lwIP's `smtp_opts.h`; check the actual value in your vendor SDK's configuration file)

  • Whether the SMTP server your device connects to is trustworthy, and whether responses could be tampered with on the network path

  • Even if you use STARTTLS, whether SMTP server certificate validation is performed (the TLS integration settings for the lwIP SMTP client are environment-dependent, so you need to check your own environment)

  • Whether you can add a similar clamp to the source in your environment, referring to the commit described above

■ Official Status and Open Questions

  • lwIP upstream: The fix has been merged into `master` via commit `614420f` (May 12, 2026). However, as of June 15, 2026, no new official release tag including this fix has been confirmed.

  • Savannah Bug #68313: The repository describes this as "Disclosed," but as of June 15, 2026, accessing the corresponding Savannah page returns "Permission Denied" (item not publicly viewable). This point needs verification.

  • Related Savannah Bug #68397: In May 2026, CISA reviewed a report of "multiple lwIP-related vulnerabilities" published on Sploitus. The resulting notification to the lwIP project, sent in the spirit of coordinated disclosure, was registered as Bug #68397. This page itself is public and can be viewed. The original report directs readers to VINCE for further details. On May 26, 2026, lwIP maintainer Erik Ekman commented "Fixed in bug #68313" and closed Bug #68397 as a Duplicate. This is publicly available information indicating that, at least for the publicly disclosed SMTP client issue, the matter has been addressed via Bug #68313. Note that the CERT/CC vulnerability note "VU#129944" referenced in this notification could not be found on `kb.cert.org` as of June 15, 2026, so its details could not be verified.

  • CVE: As of June 15, 2026, no CVE number has been confirmed for this SMTP client issue. Separately, CVE-2026-8836, a stack buffer overflow in the SNMPv3 USM handler, is registered in the NVD for lwIP 2.2.1, but this is a separate issue from the SMTP client AUTH response handling discussed in this article. Please do not confuse the two.

  • Remaining 12 findings: No details have been published in the xchglabs/lwip-2026-pocs repository, so neither their content nor severity can be evaluated. If they are published in the future, we plan to cover them in a separate article.

■ What's Next

If the remaining 12 findings from this "2026 security audit" are published, or if a fix related to Bug #68313 is included in an official lwIP release tag, we will cover it in a future News or Bug article.

Also, if there is interest in more detailed reproduction steps or code analysis for the SMTP client buffer overflow covered in this article, we may address it in a future Bug article.

■ Disclaimer

  • Purpose: This article is intended to introduce lwIP security-related developments based on publicly available information, and to summarize advisory notes and key points for users to check.

  • Verification: The content of this article is based on the description in the public repository and on our review of the publicly available lwIP source code. We cannot guarantee the accuracy of the third-party repository's description itself.

  • Your Responsibility: When deciding whether to apply the fix or how to respond, you are responsible for performing sufficient verification based on your project's requirements.

  • No Liability: The author assumes no responsibility for any damages or issues arising from the information in this article.

■ Closing Note

In this article, we reviewed the disclosed SMTP client buffer overflow — one of the findings from a 2026 security audit reported for lwIP — based on the publicly available source code.

Because lwIP is a widely used open-source project, similar vulnerability reports may be published in the future. In the News series, we plan to organize these external developments and, where appropriate, dig deeper in individual articles.

lwIP is free to use 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 vendor or manufacturer is ultimately responsible 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

We hope this helps.

More practical articles about lwIP issues will follow.

▶ English article index: lwIP Troubleshooting Notes

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