[Bug libc/524] New: Incorrect address ordering by getaddrinfo

[Bug libc/524] New: Incorrect address ordering by getaddrinfo

[fredrik@dolda2000.com]

I call getaddrinfo on a host on my network, which has these two addresses:
192.168.0.7
2002:52b6:8514:100::3

The host I'm calling it on has these addresses:
192.168.1.254
2002:52b6:8514:200:76ff:fe3b:a3f4

The problem is that in the returned set of addresses, the IPv4 address is sorted
before the IPv6 address, even though it should be the opposite according to Rule
6, Section 6 in RFC 3484, which specifies that the address of higher precedence
should be sorted first. According to the default precedence table in RFC 3484,
IPv6 addresses have higher precedence than IPv4 addresses.

-- 
           Summary: Incorrect address ordering by getaddrinfo
           Product: glibc
           Version: 2.3.3
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: fredrik at dolda2000 dot com
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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.

[Bug libc/524] Incorrect address ordering by getaddrinfo

[fredrik@dolda2000.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.

[Bug libc/524] Incorrect address ordering by getaddrinfo

[fredrik at dolda2000 dot com]

------- Additional Comments From fredrik at dolda2000 dot com  2005-01-03 03:50 -------
Created an attachment (id=333)
 --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=333&action=view)
Patch to fix this bug

This patch fixes the bug described in the bug report.

-- 


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.

[Bug libc/524] Incorrect address ordering by getaddrinfo

[fredrik at dolda2000 dot com]

------- Additional Comments From fredrik at dolda2000 dot com  2005-01-03 03:52 -------
I added a patch (against CVS) that fixes this bug. I'd really like to see this
fixed.

-- 


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.

[Bug libc/524] Incorrect address ordering by getaddrinfo

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2005-09-26 16:11 -------
The patch seems correct, applied to the CVS trunk.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/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.