Buffer overruns in libltdl/ltdl.c

[Julian Seward]

I just looked at rev 1.163 in your CVS repo, and it's definition
of realloc is similarly broken (assuming my analysis below is
correct).  Are you aware of this?

J


-------- Original Message --------
Subject: Buffer overruns in kdelibs/libltdl/ltdl.c
Date: Mon, 18 Mar 2002 02:32:23 +0000
From: Julian Seward <address@hidden>
Reply-To: address@hidden
To: address@hidden


I spotted with valgrind the other day some invalid reads in here
and chased them this evening.  It happens only when reading very 
long lines (> 1024 bytes) from a .la file.

The lines of the .la file are read one by one into a buffer "line"
(decl ltdl.c:2102, initial alloc at ltdl.c:2177) which is initially 
LT_FILENAME_MAX (1024) bytes long.

If some line turns out to be longer than this, the buffer size
is doubled:

ltdl.c:2200    line = LT_DLREALLOC (char, line, line_len *2);

LT_DLREALLOC becomes to a call to rpl_realloc, which attempts
to be a replacement for the usual realloc.  This allocates a 
new block of the new size, and then copies the contents of the
old block into it:

ltdl.c:515        memcpy (mem, ptr, size);

Problem is that "size" is the new size.  Since the new block 
is bigger than the old, this succeeds in copying garbage past
the end of the old block, into the new block.  In this case it
copies 1024 bytes of garbage, which is potentially pretty serious
-- it's not inconcievable that this could crash an app.

Thinking further, I don't understand how anyone could hope to
write a replacement for realloc which works correctly without
knowing the size of the old block, yet that's exactly what this
appears to be.

Can someone else check my logic and tell me I'm not crazy? 

I volunteer to fix it and send a patch, but it would be good
to know I'm not missing something obvious here.

J