[GRASS5] Buffer overflow in G_recreate_command()...

[Glynn Clements]

Eric G. Miller wrote:

> On Mon, Jun 04, 2001 at 07:57:25AM +0100, Glynn Clements wrote:
> > Note that the driver reads the second argument for PAD_APPEND_ITEM
> > (and most other commands which take an arbitrary string as an
> > argument) into a 1024 byte buffer.
> > 
> > This limitation is simply a result of process_command() using a
> > fixed-size buffer for reading strings from the client; there isn't any
> > limitation elsewhere.
> > 
> > Any suggestions as to how big this buffer ought to be? Or does it need
> > to be dynamically allocated?
> 
> I don't know that the buffer needs to be bigger, but maybe.  With the
> PAD_LIST, it appears the data eventually gets put in dynamic memory
> anyway.  One possibility would be to add a "SIZE" argument to the text
> commands so the read commands would know exactly how much space to
> allocate and if the "transaction" was complete.  Other possibility is to
> make the buffer "ARG_MAX" + 1 size, though that may be a little greedy
> (around 13.5k here...).

ARG_MAX is 128kb on Linux 2.4; even greedier. Stevens implies that
sysconf(_SC_ARG_MAX) is 1Mb on SunOS 4.1.1, although it doesn't say
whether the ARG_MAX macro is the same. Ultimately I don't think that
anything actually imposes an upper limit on what ARG_MAX might be.

As RECTEXT() is only ever used on two variables ("name" and "text"),
I'll change it to dynamically (re)allocate the memory.

-- 
Glynn Clements <glynn.clements at virgin.net>