OpenSMTPD — five upstream hardening fixes committed 2026-05-26

1. Summary

On 2026-05-26 Gilles Chehade (poolpOrg@), the lead maintainer of OpenSMTPD, committed five hardening patches to usr.sbin/smtpd/ in the OpenBSD tree. All five name me as the diff author. The fixes are:

• 388bcda — Reject oversized sockaddr payloads received over privsep IPC — mproc.c
• 3b4f66f — clear userinfo before sending over imsg — lka.c
• c2e63d9 — Ensure pending asynchronous lookups do not retain dangling smtp_session references after teardown — smtp_session.c
• b529354 — validate encrypted queue buffer sizes before processing auth tag and IV data — crypto.c
• 2c717ae — Zero the temporary envelope parsing buffers before use — queue_backend.c

None of the five is remote code execution. The framing of the original 2026-05-23 disclosure as “chained to Remote/Local Code Execution” was wrong and was retracted on 2026-05-26 before the upstream commits were made. The five fixes that landed are defense-in-depth on three real source-level defects (PR:H IPC overflow, same-uid stack residue, conditional remote DoS) and hardening on two paths where the original exploit framing did not hold up under verification. The complete history is documented in §3.

2. The five fixes

2.1 — 388bcda — m_get_sockaddr oversized payload rejection (mproc.c)

Subject: Reject oversized sockaddr payloads received over privsep IPC.

File: usr.sbin/smtpd/mproc.c — m_get_sockaddr().

Severity: Defense-in-depth, PR:H in CVSS terms — reaching the underlying defect requires a peer mproc process (lka, smtp, mta) already running as the privileged _smtpd user. Not pre-auth network RCE.

Upstream commit body (verbatim, public): “This is not an issue on its own but may permit lateral movement or memory corruption inside the privsep environment after another bug.”

Commit URL: github.com/openbsd/src/commit/388bcda

2.2 — 3b4f66f — userinfo zero-init before IPC (lka.c)

Subject: clear userinfo before sending over imsg.

File: usr.sbin/smtpd/lka.c — struct userinfo on-stack initialisation in the IMSG_MDA_LOOKUP_USERINFO handler path.

Severity: Trivial same-uid (_smtpd → _smtpd) stack-residue information leak. Not a privsep boundary leak. Defense-in-depth memset; an attacker who has already compromised one _smtpd process to receive the leak does not need a leak.

Commit URL: github.com/openbsd/src/commit/3b4f66f

2.3 — c2e63d9 — smtp_free wait-tree dangling references (smtp_session.c)

Subject: Ensure pending asynchronous lookups do not retain dangling smtp_session references after teardown.

File: usr.sbin/smtpd/smtp_session.c — smtp_free() wait-tree popping.

Severity: Real use-after-free reachable when the administrator has configured hostnametable (or another lka-side table) on a listener. Crash-grade remote DoS, conditional on admin configuration. Not code execution.

Upstream commit body (verbatim, public): “This is mainly a robustness fix inside the privsep model: stale references may permit lateral effects between smtpd processes after another compromise.”

Commit URL: github.com/openbsd/src/commit/c2e63d9

2.4 — b529354 — encrypted-buffer size validation (crypto.c)

Subject: validate encrypted queue buffer sizes before processing auth tag and IV data.

File: usr.sbin/smtpd/crypto.c — crypto_decrypt_buffer().

Severity: Hardening. The arithmetic size_t underflow that my original 2026-05-23 mail flagged does exist (for inlen < sizeof tag, inlen - sizeof tag underflows), but the resulting near-SIZE_MAX value lands in the safe return 0 decrypt-failure path. The dangerous memcpy(tag, in + inlen - 16, 16) is never reached. I retracted the exploit framing in my 2026-05-26 corrected per-claim reply to the OpenBSD security team. Upstream shipped the explicit input validation as defense-in-depth.

Commit URL: github.com/openbsd/src/commit/b529354

2.5 — 2c717ae — envelope-parsing buffer zero-init (queue_backend.c)

Subject: Zero the temporary envelope parsing buffers before use.

File: usr.sbin/smtpd/queue_backend.c — queue_envelope_load_buffer() compbuf / encbuf stack buffers.

Severity: Defense-in-depth zero-initialisation of two stack buffers used during envelope parsing.

Commit URL: github.com/openbsd/src/commit/2c717ae

3. Fix availability

All five commits listed in §2 landed in OpenBSD −current on 2026-05-26. The exact tree state can be verified against the openbsd/src mirror at the cited commit hashes.

Release timing and backport decisions are the OpenBSD project’s call. The practice does not speculate on which release will include these commits, or on whether any will ship as −stable errata against the supported branches. The authoritative sources are:

• openbsd.org — current released version and release notes
• openbsd.org/faq/faq5.html — release / −current / −stable policy
• openbsd.org/errata79.html — OpenBSD 7.9 errata
• openbsd.org/errata78.html — OpenBSD 7.8 errata
• github.com/openbsd/src — tree mirror; commits can be verified directly

The lka-side hostnametable path is the operational hook worth noting in the interim: a listener configured without hostnametable (or another lka-side table) does not reach the c2e63d9 use-after-free path.

The OpenSMTPD-portable distribution at github.com/OpenSMTPD/OpenSMTPD is a separate downstream of the OpenBSD base tree and follows its own release process. Operators using that distribution should track that repository for downstream pickup.

4. Disclosure history

The honest history matters and is in scope for this disclosure.

2026-05-23. I sent security@openbsd.org a six-claim disclosure titled Multiple Critical Vulnerabilities in OpenSMTPD (Buffer Overflows, UAF, Info-Leaks). The mail framed the six findings as chainable, with the sentence: “When chained, the Information Leaks bypass ASLR/RETGUARD to allow the stack buffer overflow to achieve Remote/Local Code Execution.” That framing was wrong. The disclosure had been produced from an AI-assisted source review that I had not independently verified against the current OpenBSD 7.8 amd64 tree before sending, and the “chained to RCE” framing was inflation that the source observations did not actually support.

2026-05-23, same day. Theo de Raadt (deraadt@) replied with a single pointed question, paraphrased here with respect to the privacy of security@ correspondence: whether I was actually claiming to have exploited the chain to gain privileges; whether execution had been achieved.

The honest answer was no. I had not built a chain, had not achieved execution, and had not produced a working PoC against any of the six claims. Each claim contained a real source observation, but the chain framing was assembled rather than demonstrated.

2026-05-25. I performed per-claim verification of each of the six original claims against the current /usr/src/usr.sbin/smtpd/ tree at OpenBSD 7.8 amd64. Three of the six were real source-level defects but at one to three severity steps below the framing in the original mail. One was a trivial same-uid IPC stack-residue leak (not a privsep boundary leak as the original mail had implied). Two were fabricated and retracted in full — one (the smtp_reply vsnprintf %.*s claim) had no current format string that could produce the required trigger; the other (the crypto_decrypt_buffer exploit framing) failed the caller-bounds trace and lands in the safe decrypt-failure path. The verification record is preserved in the project's findings directory.

2026-05-26, 07:00 UK. I sent Theo a corrected per-claim reply. The opening sentence was “No. I did not achieve execution.” The rest of the mail was per-claim correction without padding.

2026-05-26, 14:31 UK. Theo replied (paraphrased): he was forwarding the corrected per-claim list to the OpenSMTPD maintainers, who would commit what they judged worthwhile; some changes might be verbatim, others might be modified, the outcome was theirs to decide.

2026-05-26, hours later. Gilles Chehade (poolpOrg@), OpenSMTPD's lead maintainer, committed the five patches listed in §2 to openbsd/src. All five name me as the diff author.

This is the resolution the original mail did not deserve. It happened because OpenBSD's posture treats corrections as worth reading rather than as evidence to escalate against the reporter. Both Theo and Gilles handled the case professionally throughout.

5. What this disclosure is not

Explicit non-claims, because the original mail’s framing earned the explicit walk-back.

• None of the five fixes is remote code execution. The most severe fix in the batch (c2e63d9, the smtp_free wait-tree UAF) is a crash-grade remote denial of service conditional on the administrator having configured a relevant lka-side table on a listener.
• There is no chain. The original 2026-05-23 framing of “chained to RCE” was inflated and was retracted in full on 2026-05-26 before the upstream commits.
• Two of the original six claims were retracted as fabricated — the smtp_reply vsnprintf %.*s trigger (no current format string in smtp_reply produces a write greater than the 4096-byte buffer), and the crypto_decrypt_buffer exploit framing (the underflow lands in the safe decrypt-failure path; the dangerous memcpy is never reached). Upstream shipped the crypto.c input validation anyway as defense-in-depth (b529354), but the exploit story behind it does not hold.
• A sixth real defect from the original mail — a double-close in queue_message_fd_r()'s error path in queue_backend.c — is not in this 2026-05-26 batch. Whether it lands as a separate upstream commit is for the maintainers to decide.
• This disclosure does not request a CVE. Defense-in-depth and conditional-DoS findings without a demonstrated exploitable trigger do not meet the bar most CVE numbering authorities apply; the five upstream commits are the record of the work.

6. Methodology context

The methodological lesson behind the walk-back — AI-assisted source review is useful but is not ground truth, and a pre-send filter is needed to catch the mechanical failure modes (bug-shape fabrication, evidence fabrication, severity inflation, trivial-as-critical) before a draft reaches a maintainer’s inbox — is the subject of a separate methodology paper:

The Calculator Discipline: A Taxonomy and Pre-Send Filter for AI-Assisted Vulnerability Disclosure Hallucinations (S. Thomas, 2026), DOI 10.5281/zenodo.20393083.

That paper documents this OpenSMTPD case as its second case study. The four-verifier pre-send filter described in the paper’s §6 (hallucination_check.py) ships as part of the open-source penfold toolkit at github.com/jetnoir/penfold (BSD-2-Clause), under penfold.disclose.hallucination_check. The original 2026-05-23 mail would have triggered severity_inflation and caller_bounds_gate verdicts had the tool existed at the time of drafting.

Walking the framing back rather than defending it is part of the methodology, not an exception to it. A paper on disclosure hallucination by an author who had not himself hallucinated would be a thinner paper.

7. Credit

Gilles Chehade (poolpOrg@opensmtpd.org) — OpenSMTPD’s lead maintainer; authored all five upstream commits and shipped them on 2026-05-26.

Theo de Raadt (deraadt@openbsd.org) — for the pointed reply on 2026-05-23 that forced the methodology correction, and for forwarding the corrected per-claim list to OpenSMTPD upstream on 2026-05-26.

Stuart Thomas — credited as “diff by Stuart Thomas <stuart.thomas@triageforge.co.uk>” on all five commits.

None of the named maintainers endorses the framing of this disclosure or the methodology paper that accompanies it; they are credited here only for the public work of theirs that made these fixes possible.

Legal note

This disclosure is published under the Defamation Act 2013 facts-and-opinion convention. Statements of fact — commit hashes, dates, vendor responses, code excerpts, source-tree paths — are accurate to the best of the author’s knowledge and are evidenced by the OpenBSD CVS commit log, the public github.com/openbsd/src mirror, and the author’s contemporaneous correspondence with the OpenBSD project. The verbatim text of security@openbsd.org correspondence is not reproduced here out of respect for the list’s private status; paraphrasing in §3 preserves the substance.

The OpenBSD project is named as the publicly-accountable maintainer of the affected software. Individual developers (Gilles Chehade, Theo de Raadt, and others) are named only in their public capacity as committers and maintainers, and only in connection with their own public commits and public mailing-list traffic. They are characterised, where mentioned, as professional and prompt; this is the author’s honest experience of them.

The research was conducted on hardware owned by the author. No third-party systems were accessed in the course of the research. The work was performed within the scope permitted by the Computer Misuse Act 1990 (England and Wales) own-hardware exemption.

Coordinated disclosure of vulnerabilities in network-facing software is a matter of legitimate public interest under s.4 of the Defamation Act 2013. This disclosure, including its explicit walk-back of the original 2026-05-23 framing, is published in good faith on that basis. Where any fact has been described inaccurately, the author will correct it; please email stuart.thomas@triageforge.co.uk.