Re: GNU inetutils telnet client: SLC LINEMODE global buffer overflow and address disclosure

Simon Josefsson via Bug reports for the GNU Internet utilities <[email protected]> Mon, 13 Jul 2026 18:19:21 +0200
Newsgroups gmane.comp.gnu.inetutils.bugs
Message-ID <[email protected]>
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=EC=9E=84=EC=A4=80=ED=98=81 via Bug reports for the GNU Internet utilities
<[email protected]> writes:

> The client appends LINEMODE SLC reply triplets to the fixed 128-byte glob=
al
> buffer `slc_reply` through `slc_replyp`, without checking the remaining
> space:
>
>   telnet/telnet.c:1484-1489, slc_add_reply()
>
> A malicious or impersonated Telnet server can negotiate LINEMODE and send=
 an
> oversized SLC suboption. For `func > NSLC` with supported SLC level bits,
> `slc()` repeatedly calls:
>
>   slc_add_reply (func, SLC_NOSUPPORT, 0);
>
> This overflows `slc_reply[128]`. `slc_end_reply()` also writes its final
> `IAC SE` bytes without a bound check and derives the network reply length
> from the potentially corrupted cursor.

Thanks for your analysis and report!  Seems reasonable.  I've pushed:

https://codeberg.org/inetutils/inetutils/commit/27ef59f916ff26cc14fe63743d9=
b7a3dd49937cb

It would be great if you could confirm this resolve this problem?

How did you find this?  Were tools (e.g., LLMs) used, if so which one?

It would be great if we could add a test harness that would trigger
these bugs in an ASAN build, to have further confidence that patches
actually solve some identified problem.  It shouldn't be hard to write,
but getting it run predictable and without flaky errors on all platforms
is probably more challenging.

/Simon

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmpVEAkUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJp4fWRBQkOa+rdAAoJENc89jjFPAa+hWIA
/1lQvrJeGlQq50lP6tm99D1zDy7J1tQ3ha4x0Jx7rkFTAP9hpUKuTvm6m1fXyiZV
YZlu2+Id/Dq3CIAZvNF+XEr2BLgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCaeCW1wUJDmqLVgCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+s7AA+gIIHpBApDpcDj1sKhzDngmpvwQf0VkHme6s+EG7qSgpAQDe
/XMrU0c0Pa3ji85cMqZhvzJOFI/soe662lzL0QY3Bbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJp4JbXBQkOaottAAoJENc89jjF
PAa+RNUA/2faQO/nFT06E+MlhlQdo/0chlQXC5TZMPTVvVBFwoLOAP9xLJK0ow5E
jTzYJB4K810AL/Iv6PEOAEgA4cPTHVlbCQAKCRBRcisI/kdFon05AQDZ5TJv204h
LKxTbR5+nzQ+5BO+n2mL9o8cPJpQY4XTYAEAqLU5HMYwxQEq4z+43rIJD3H6AqM8
FeyYMsULkoEoNQw=
=wQZQ
-----END PGP SIGNATURE-----
--=-=-=--