On Sat, Jul 01, 2006 at 01:51:34PM +0200, Ludovic Rousseau wrote: > The bug is classic: off-by-one buffer overflow. > > The function make_content() in libdb/db_lookup.c calculates the size > needed for cont.dptr but forget to include the final NUL byte. > > Please apply this proposed patch. > > diff -r --unified=10 man-db-2.4.3/libdb/db_lookup.c > man-db-2.4.3.new/libdb/db_lookup.c > --- man-db-2.4.3/libdb/db_lookup.c 2003-11-16 19:46:47.000000000 +0100 > +++ man-db-2.4.3.new/libdb/db_lookup.c 2006-07-01 13:40:12.000000000 > +0200 > @@ -254,21 +254,21 @@ > in->whatis = dash + 1; > > cont.dsize = strlen (dash_if_unset (in->name)) + > strlen (in->ext) + > strlen (in->sec) + > /* strlen (in->_st_mtime) */ + 11 + > /* strlen (in->id) */ + 1 + > strlen (in->pointer) + > strlen (in->filter) + > strlen (in->comp) + > - strlen (in->whatis) + 8; > + strlen (in->whatis) + 8 +1; > cont.dptr = (char *) xmalloc (cont.dsize); > #ifdef ANSI_SPRINTF > cont.dsize = 1 + sprintf (cont.dptr, > "%s\t%s\t%s\t%ld\t%c\t%s\t%s\t%s\t%s",
Actually I'm not sure this is correct. Break down the string: name \t ext \t sec \t mtime \t id \t pointer \t filter \t comp \t whatis Now the mtime is 10 digits long at most so the 11 in the code already includes its trailing tab. That means there are 7 tab characters not taken into account by the sum of the strlens, and the final NUL makes 8. The calculation seems correct to me. (I concede that the code is very confusingly arranged, and I just committed a change to upstream CVS to make it slightly less so.) Presumably you've now dug into the problem somewhat; could you include some of your intermediate results? For example, is there a particular man page or package I can install that will allow me to reproduce the problem? Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
