BUG in art.c:2284 ARTpost() causes core

[Kai 'wusel' Siering]

Moin,

N wrote:
 
% Miquel van Smoorenburg wrote:
% 
% > Yes the code looks that way, but there's a bit more to it. Look at
% > a gdb strace of a crashed innd:
% > 
% > #0  0x8067362 in MaxLength (p=0x0, q=0x0) at innd.c:134
% > 134         i = strlen(p);
% > (gdb) up
[...]
% > (gdb) print distributions[0]
% > $1 = 0x0
% > 
% > As you can see distributions[0] is most certainly NULL, and dereferencing
% > it as *distributions[0] will cause a coredump.
% > 
% > In fact that is WHY innd crashed in the first place; the dereference
% > of distributions[0] in the sprintf() ...
% 
% In fact it was calling strlen() on it.

Yepp.

% Libc's printf of most platforms
% just outputs (null) instead of coring. FreeBSD, Linux and IRIX live,
% SunOS 5.x dies.

Kind of a philosophical discussion, whether or not libc has to
function as a safety belt for buggy software, isn't it? A bug is
a bug, even under FreeBSD, Linux and IRIX ;)

I added something along

	if(!p || !q) {syslog(); buf[0]='\0'; return(buf);}

in MaxLength() to make sure that beast won't bite my servers
again.

As to the published patch: my understanding is that neither

	if (distribution[0] == '\0')

nor

	if (*distribution[0] == '\0')

addresses the problem in question. Only

	if (distribution[0] == NULL)

does, since distribution[0] is a pointer to char, not a char, and
the issue is not whether any string is empty but whether a pointer
(to char) points to NULL.

% The article that caught me was <942925094.1792snx at wang.pc.my>, apparently
% containing Distribution: \r\n as `print Data' in gdb shows.

It was "Distribution: ,". Regards,
			kai

-- 
Kai 'wusel' Siering                       eMail @ home: wusel at uu.org
Traveller on the Information Highway doing full-time administration.
 
The views expressed here are not neccessarily those of any employer.