Path: utzoo!utstat!helios.physics.utoronto.ca!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!stl!neon!helium!duncan From: duncan@helium.siesoft.co.uk (Duncan McEwan) Newsgroups: news.software.nn Subject: Re: nnmaster dies Message-ID: <1811@neon.siesoft.co.uk> Date: 26 Feb 90 13:23:34 GMT References: <5317@m2c.M2C.ORG> Sender: news@neon.siesoft.co.uk Lines: 44 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.