🚀 go-pugleaf

davison@drivax.UUCP (Wayne Davison) writes:

>If you have a pre-6.3.6 version of nn, you still have a bug in the name
>compression routine that will cause nn to crash when the name header is
>longer than 256 (or so) bytes.

I "discovered" a bug that sounds just like this one in my 6.3.1 sources
last week, but on grabbing 6.3.7 over the weekend and having a quick
look at it, the same bug still appears to be there -- so perhaps it is
a different one to that mentioned by Wayne.

The one I found is in pack_name.c ...

> pack_name(dest, source, length)
> char *dest, *source;
> int length;
> {
>    register char *p, *q, *r, c;
>    register int n;
>    char namebuf[129], *name;
>    ...
>    p = source, q = namebuf, n = 0;
>    
>    ...
>
>	*q++ = c;

As far as I can see, there is nothing to protect *q++ from overwriting
the stack if the name in the From: line is longer than 129 chars.  Last
week we received just such an article which caused nnmaster to core dump
everytime it tried to process it.  The hack fix I applied was to guard
the assignment statment by a check on the length of (q - namebuf).
I am uncertain as to whether this will have subtle adverse effects on the
remainder of the name parsing code (since it is now possible for there to
be mismatched parenthesis, etc).

The above source fragment (and in fact the whole pack_name.c file) is identical
in 6.3.1 and 6.3.7).  Perhaps the above bug has been fixed elsewhere in
the routines that read the header into memory, but from a quick look through
open_news_article() and parse_header() I couldn't see that it had.  Can
anyone tell me if I am missing something, or has this particular bug not
been fixed until after 6.3.7?

Duncan.