[Bug libc/524] Incorrect address ordering by getaddrinfo

["fredrik at dolda2000 dot com" <sourceware-bugzilla at sources dot redhat dot com>]

------- Additional Comments From fredrik at dolda2000 dot com  2004-11-08 15:16 -------
It seems that there is an error in sysdeps/posix/getaddrinfo.c that causes this.
In the match_prefix function, there is this code snippet:

  for (idx = 0; ; ++idx)
    {
      unsigned int bits = list[idx].bits;
      uint8_t *mask = list[idx].prefix.s6_addr;
      uint8_t *val = in6->sin6_addr.s6_addr;

      while (bits > 8)
        {
          if (*mask != *val)
            break;

          ++mask;
          ++val;
          bits -= 8;
        }

      if (bits < 8)
        {
          if ((*mask & (0xff00 >> bits)) == (*val & (0xff00 >> bits)))
            /* Match!  */
            break;
        }
    }

  return list[idx].val;

As you can see, there's no matchine case when there is exactly 8 bits left to
match, which causes the loop to go on with the next prefix in the list, as if it
didn't match, so as long as all prefixes have lengths that are divisible by 8,
the last value (with a 0 bit prefix) will always be returned.

I suggest changing the first case to while(bits >= 8) to resolve this.

Also, I have to say that I'm unsure about the match_prefix function and the
prefixlist struct in general. I'm haven't examined this in detail, but won't it
malfunction on LSB architectures if the bit number isn't divisible by 16, since
the bytes are stored in opposite order of what they are typed into the
prefixlists? It seems to me that the prefixlist arrays should be initialized
with the 8-bit entries in in6_u. Maybe that's just my imagination, though -- I
haven't actually tried debugging it.


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=524

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.