[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in telnet from inetutils-2.2: Insufficient buffer space for long

From: Erik Auerswald
Subject: Re: Bug in telnet from inetutils-2.2: Insufficient buffer space for longish DISPLAY names
Date: Mon, 7 Feb 2022 11:07:56 +0100
User-agent: Mutt/1.5.21 (2010-09-15)


On Sat, Feb 05, 2022 at 05:18:01PM +0100, Erik Auerswald wrote:
> On 01.02.22 10:01, Erik Auerswald wrote:
> >
> >I am a colleague of Joerg and could reproduce the bug on Ubuntu GNU/Linux
> >with a freshly built telnet client from GNU inetutils 2.2:
> >[...]
> >Thus the second hunk of the diff sent by Joerg is the actual bug fix,
> >i.e., retracting use of the X Display Location option.
> To fix the bug, you can just copy line 1007 of telnet/telnet.c to
> somewhere after line 1017, but before (current) line 1019, to treat
> this error of a too long DISPLAY variable value similar to somehow
> losing the DISPLAY variable after announcing to send the "X Display
> Location" option.  The problem is similar, i.e., the telnet client
> tells the server that it will send this option, but then detects
> that it cannot do so.  Thus the solution should be similar, i.e.,
> retracting use of the option and optionally emitting an error message.
> I would be quite surprised if this description of the bug fix would
> be copyrightable.

Apples telnet client for macOS, included in the remote_cmds package,
contains an equivalent fix for this issue since at least version 12
and still contains it in the latest version 63.  In this telnet client,
an overlong DISPLAY value is silently ignored.

The telnet clients of Free-, Net-, and OpenBSD just truncate an
overlong DISPLAY value, as did GNU inetutils telnet before commit
07fdb4201a3a5e6df92c0929c65671ce4ba8af5a.  They all use a buffer of 50
bytes to hold the telnet suboption negotiation byte sequence.

The NetKit telnet client as found in Debian GNU/Linux truncates an
overlong DISPLAY variable, too, but seems to use a 256 byte buffer.

There are a couple of workarounds available right now:

1. A portable workaround that disables sending the X Display Location
   option is to start the telnet client in a subshell where the DISPLAY
   variable has been cleared:

    $ (unset DISPLAY; telnet ...)

2. Starting the telnet client without arguments, clearing the DISPLAY
   environment variable, and then opening the remote connection:

    $ telnet
    > environ undefine DISPLAY
    > open ...

3. Using the (in GNU inetutils telnet undocumented) command
   "send wont XDISPLOC" resp. "send wont 35":

    $ telnet ...
    Trying ...
    Connected to ...
    Escape character is '^]'.
    lm_will: not enough room in buffer
    telnet> send wont XDISPLOC

Best regards,
Simplicity is prerequisite for reliability.
                        -- Edsger W. Dijkstra

reply via email to

[Prev in Thread] Current Thread [Next in Thread]