Subject: GNU inetutils telnet client: SLC LINEMODE global buffer overflow and address disclosure
Hello GNU Inetutils maintainers,
We would like to report a client-side memory corruption and information
disclosure issue in GNU inetutils telnet.
The client appends LINEMODE SLC reply triplets to the fixed 128-byte global
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.
We validated two effects on GNU inetutils 2.8 under Ubuntu 24.04.4 LTS on
WSL,
x86-64, GCC 13.3.0:
1. An ASan build reports a global-buffer-overflow in `slc_add_reply()` at
telnet.c:1486.
2. In an otherwise identically configured non-ASan `-O0` PIE build where
the storage for the global `slc_replyp` variable begins at
`slc_reply + 0x80`, a partial overwrite of `slc_replyp` causes
`slc_end_reply()` to copy bytes beyond `slc_reply` into the network
ring.
The supplied two-stage PoC receives BSS/PIE pointers and derives the
randomized `slc_reply` address.
The demonstrated disclosure is layout-dependent. We are reporting a
validated
BSS/PIE address disclosure; we are not claiming a heap disclosure,
arbitrary-address read, or arbitrary-width write.
We also reviewed Savannah revision
7c58506a8eadbc4b57ccb330babed31dd5a5558f. `git ls-remote` confirmed on
2026-07-13 that this revision is both HEAD and master. Its latest commit is
dated 2026-05-04 (`whois: don't overflow a buffer when the servers doesn't
send
a newline`), and the vulnerable path remains present.
Although this is the same vulnerability class as CVE-2005-0469 in
BSD-derived
Telnet clients, the corresponding `slc_add_reply()` path remains unpatched
and
exploitable in GNU inetutils `telnet`. We are therefore reporting it for
remediation and appropriate vulnerability tracking.
The attached report contains the source walk-through, identical configure
options for ASan and non-ASan builds (only CFLAGS/LDFLAGS differ), exact
direct
run commands, representative ASan and leak output, and remediation guidance.
The PoC uses `--crash` for ASan validation and defaults to the two-stage
leak
mode for the matching non-ASan build.
A complete fix should bound every escaped SLC triplet append while reserving
space for the final marker, and independently guard the `IAC SE` writes in
`slc_end_reply()`.
Credit
------
We would appreciate it if you could credit this finding to Junhyuk IM(S2W)
and Seungyun Lee(S2W).
Regards,
Junhyuk IM(S2W)
Seungyun Lee(S2W)
<<attachment: inetutils-client-slc-disclosure.zip>>
