[scponly] Re: scponly bug

[Karl DeBisschop]

On Tue, 2002-09-17 at 03:58, joe wrote:

> > > On Mon, 16 Sep 2002, Zdenek Hladik wrote:
> > >
> > > > But more serious problem i got. At first I believed that i made wrong
> > > > chroot jail, but after adding some debug messages to scponly.c i
> > > > found that scponlyc crashes inside
> > > >
> > > >        flatten_vector()
> > > >
> > > > on processing of scp -r -p -d "somefile" command from winscp. with
> > > > exit signal 11 (memory violation).

splint flags the following code as a use of already freed memory:

		if (NULL == (temp = realloc (outbuf, newlen)))
		{
			perror("realloc");
			if (outbuf)
				free(outbuf);
			exit(-1);
		}

I think it is right. I think of it like this: realloc takes an existing
memory segment, and hands you a new segmant of the requested size,
preserving the contents of the old segment if it fits within the length
of the returned memory space (which may or may not start at the same
point as the old pointer). So outbuf is actually freed by realloc.

Now it could be that I'm not uderstanding it fully, but if the logic
above (and the splint output) are correct, then 

		if (NULL == (temp = realloc (outbuf, newlen)))
		{
			perror("realloc");
			exit(-1);
		}

is the correct code.

Even if there's argument about whether or not it's correct, omitting the
free() does clear up the splint error, and since the next call is to
exit(), there would be no real consequence to leaving outbuf unfreed.

-- 
Karl DeBisschop <kdebisschop at alert.infoplease.com>