Hi all, Sorry for the delay - it took me a bit longer than I meant to send this. Attached is our security advisory for CVE-2026-32746 regarding the GNU Inetutils telnetd SLC issue.
Best regards, Adiel Sol DREAM Security Research Team ________________________________________ From: Simon Josefsson Sent: Thursday, March 12, 2026 5:47 PM To: Adiel Sol Cc: Collin Funk; [email protected] Subject: Re: Remote Pre-Auth Buffer Overflow in GNU Inetutils telnetd (LINEMODE SLC) Adiel Sol <[email protected]> writes: > Hi Guillem, Simon, Colin, > > Thank you for your reply and for clarifying how things work. > I will write the security advisory in the next few days and send it to > you. I will also start the CVE process on our side, and once we have a > CVE assigned I will share the CVE number with you. Wonderful! Thank you for careful reviewing code and looking at InetUtils, and I hope you will continue to study the code. /Simon > Best regards, > Adiel Sol > DREAM Security Research Team > > > ________________________________________ > From: Simon Josefsson > Sent: Thursday, March 12, 2026 2:53 PM > To: Adiel Sol > Cc: Collin Funk; [email protected] > Subject: Re: Remote Pre-Auth Buffer Overflow in GNU Inetutils telnetd > (LINEMODE SLC) > > Adiel Sol <[email protected]> writes: > >> Hi Collin, >> Thank you for confirming the findings and for the pull request and the >> credit in the NEWS file; we really appreciate it. >> A couple of questions about disclosure: >> >> 1. Are you planning to request a CVE for this issue (e.g. through >> the GNU project or another CNA), or would you prefer that we request >> it from our side? > > GNU is not a CNA, so please assign a CVE if you can do this. We can > include it in the NEWS entry. > >> 2. >> Do you have a rough timeline for when the fix will be released >> (e.g. next release or patch branch), and when you expect to publish >> the CVE or security advisory? > > Adiel or Colin, do you want to write a security advisory? Maybe use the > following for inspiration: > > https://lists.gnu.org/archive/html/bug-inetutils/2026-01/msg00004.html > > I think we have worked up to a new release, so let's plan that for no > later than April 1st. > >> 3. >> What is your preferred process from here until public disclosure >> (e.g. embargo period, coordinated advisory, or anything we should >> avoid doing until a certain date)? > > The bug-inetutils is a public list, so this is already public. I'm not > aware of any need to do anything further except make the release, and if > someone has time, also write an advisory about this. > > /Simon > >> We are happy to align with your process and timeline. >> Best regards, >> Adiel Sol >> DREAM Security Research Team >> >> >> >> >> ________________________________ >> From: Collin Funk <[email protected]> >> Sent: Thursday, March 12, 2026 9:49 AM >> To: Adiel Sol <[email protected]> >> Cc: [email protected] <[email protected]> >> Subject: Re: Remote Pre-Auth Buffer Overflow in GNU Inetutils telnetd >> (LINEMODE SLC) >> >> [You don't often get email from [email protected]. Learn why this >> is important at https://aka.ms/LearnAboutSenderIdentification ] >> >> Adiel Sol <[email protected]> writes: >> >>> Proof of Concept >>> >>> 1. Start GNU Inetutils telnetd (e.g. with inetd or run telnetd >>> manually) so it listens on port 23. >>> 2. From another machine, connect to the telnet port and complete the >>> initial handshake. When the server sends DO LINEMODE, reply with >>> WILL LINEMODE so the server enters LINEMODE negotiation. >>> 3. Send a single LINEMODE SLC suboption containing at least 40 to 50 >>> triplets, each with a function code greater than 18 (e.g. 19, 20, 21, >>> ... 68). Each triplet is 3 bytes (func, flag, value). Use 0x00 for >>> flag and value. The suboption must be properly framed with IAC SB >>> LINEMODE LM_SLC at the start and IAC SE at the end. >>> 4. The server will call add_slc() for each triplet. After about 35 >>> triplets it will write past the end of slcbuf. You should observe a >>> crash, or (if you craft the overflow) memory corruption and possibly >>> code execution. >> >> Thank you for the detailed analysis and reproduction steps. I confirm >> your findings. >> >>> Credit Request >>> >>> We kindly request that the following researchers be credited for >>> this discovery: >>> Adiel Sol, Arad Inbar, Erez Cohen, Nir Somech, Ben Grinberg, Daniel >>> Lubel - DREAM Security Research Team >>> Best regards, >>> DREAM Security Research Team >> >> I submitted a pull request just now [1], and mentioned you all in the >> NEWS file. >> >> Collin >> >> [1] https://codeberg.org/inetutils/inetutils/pulls/17/files >>
# GNU Inetutils Security Advisory: telnetd LINEMODE SLC buffer overflow (CVE-2026-32746) **CVE-2026-32746** â https://www.cve.org/CVERecord?id=CVE-2026-32746 **CWE:** CWE-120, CWE-787 The telnetd server processes the TELNET LINEMODE SLC (Set Local Characters) suboption by writing client-controlled reply data into a fixed 108-byte static buffer (`slcbuf`) in `telnetd/slc.c`. The function `add_slc()` appends bytes through a write pointer but never checks whether the write would go past the end of the buffer, resulting in an **out-of-bounds write**. A remote client can send an SLC suboption containing many triplets with function numbers greater than NSLC (18). For each such triplet the server calls `add_slc(func, SLC_NOSUPPORT, 0)`, writing at least 3 bytes. After approximately 36 triplets the buffer is full; further writes go past the end of the buffer. With up to about 169 triplets in a single suboption the overflow can be on the order of 400 bytes. On builds where the write pointer `slcptr` is stored in memory immediately after the buffer, the overflow overwrites that pointer. The next `add_slc()` call then writes attacker-controlled bytes to an attacker-chosen address (write-what-where), leading to remote code execution as the telnetd process, which typically runs as root. No authentication is required; the bug is triggered during option negotiation before login. **Severity:** Critical **Vulnerable versions:** GNU Inetutils telnetd (affected code in `telnetd/slc.c`). Versions that include the vulnerable SLC handling are affected; the exact range depends on when the current SLC logic was introduced. At least versions through 2.7 are vulnerable. ## Recommendation Do not run a telnetd server if avoidable. Restrict network access to the telnet port to trusted clients. Apply the patch, or upgrade to a release that includes the fix. **This advisory is published together with a GNU Inetutils release that contains the fix.** ## Workaround If you cannot upgrade immediately, disable the telnetd server, or block access to port 23 from untrusted networks, until a fixed build is deployed. ## Patch The fix adds a bounds check in `add_slc()` so that writing a tuple does not go past the end of the buffer. The change is merged upstream and is included in the release published alongside this advisory: https://codeberg.org/inetutils/inetutils/pulls/17 ## Credits This vulnerability was found and reported by Adiel Sol, Arad Inbar, Erez Cohen, Nir Somech, Ben Grinberg, and Daniel Lubel (DREAM Security Research Team) on 2026-03. Initial report: https://lists.gnu.org/r/bug-inetutils/2026-03/msg00031.html The fix was implemented by Colin Funk (collinfunk), with review and confirmation by the maintainers. This advisory was drafted for the GNU Inetutils project with input from the reporters and maintainers.
