>>> src/lib/libc/net/gethnamaddr.c rev 1.33 should fix it.
>> So as I read it, there's a 50% chance that the danger is there; if
>> the danger is there there's a 50% chance that any particular
>> /etc/hosts lookup will trigger it, depending on whether the
>> pre-address stuff causes the two ALIGNs to align to different
>> places.  [...]  Is that correct?
> I don't think that's correct, though all of this ALIGN() stuff is a
> bit cryptic to me.

> Which two ALIGNs were you refering to?

The code in 1.30, which is what I had the problem under, looks like
(paraphrased)

	tmpbuf = 0;
	while ((p=_gethtent()) && (num < MAXADDRS)) {
		some checking
		if (num == 0) {
			bufsize = length of hostname and aliases,
				MAXADDRS addresses, plus ALIGNBYTES
			ptr = tmpbuf = malloc(bufsize);
			copy hostname and aliases into tmpbuf, advancing ptr
			ptr = ALIGN(ptr)
		}
		copy this address to ptr, increment ptr, num++
	}
	len = ptr - tmpbuf
	copy from tmpbuf to hostbuf, ptr = hostbuf
	advance ptr to skip over hostname and aliases
	ptr = ALIGN(ptr)
	set h_addr_list pointers based on ptr

> I don't think that hostbuf's alignment matters - there's an ALIGN()
> call before we access it, so if it's on an odd 4-byte boundry, we'll
> ignore the first 4 bytes and start using the space at the next 8-byte
> boundry.

Not in 1.30.  The problem is: tmpbuf is aligned (it comes from malloc),
so the first ALIGN, inside the while and if, places the addresses at a
multiple of ALIGNBYTES from the beginning.

However, if hostbuf is not aligned, then after the last ALIGN,
ptr-hostbuf may not equal what ptr-tmpbuf was after the first ALIGN.
Which, if it happens, means that the h_addr_list[] pointers point to
the wrong pieces of hostbuf.

The relevant change (from 1.32 to 1.33) ALIGN()s hostbuf before copying
tmpbuf into it.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B