[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: Tue, 1 Feb 2022 10:01:38 +0100
User-agent: Mutt/1.5.21 (2010-09-15)


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:

    $ telnet/telnet --version | head -n1
    telnet (GNU inetutils) 2.2

The problem occurred when connecting to an old OpenGear console server.
The console server seems to use some telnet server with BSD origins:

    $ strings -a telnetd | grep Copyright
    @(#) Copyright (c) 1989 Regents of the University of California.

First I'd like to expand a bit on the observable problem.  The GNU
inetutils telnet client will emit the following error message:

    lm_will: not enough room in buffer

The telnet client still works fine, i.e., keys pressed are sent to the
server and one can use the "escape character" to get a prompt and enter

The observable problem is that the telnet server does not send any data
to the telnet client.  Thus this telnet session is stuck.

No other telnet sessions are affected.  Exiting the telnet client clears
the session on the telnet server.

When the DISPLAY envorinment variable value is "too long", the GNU
inetutils telnet client will negotiate the use of the "X Display Location"
option, but will then neither send this option nor retract use of the
option.  Thus it seems that the telnet server we observed the problem
with waits for this option before completing session setup.

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.

The first hunk of the patch, increasing the static buffer used to
compose the actual telnet option data to send, allows to send larger
DISPLAY values.  Using a dynamically allocated buffer of the correct (or
sufficient) size would be better.  But the actual DISPLAY value used by
Joergs system (and most current systems) can only be used locally, not
via network.  It is thus not really useful to use it with the X Display
Location telnet option.  Additionally, the DISPLAY value can not always
be used as is for the X Display Location option, as described in RFC 1096
"Telnet X Display Location", section 5 "Implementation Suggestions"[1].
But GNU inetutils telnet just sends the original DISPLAY value.  Thus I
am not sure if it really is useful to add about 1000 bytes to the stack
to allow sending nonsensical X Display Location values.

[1] https://datatracker.ietf.org/doc/html/rfc1096#section-5

Best regards,

P.S. Please keep me in Cc: as I am not subscribed to this mailing list.
A distributed system is one in which the failure of a computer you didn't
even know existed can render your own computer unusable.
                        -- Leslie Lamport

reply via email to

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