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 <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool