Bug 174927 - pb in sysdeps/posix/getaddrinfo.c, rfc3484_sort()
pb in sysdeps/posix/getaddrinfo.c, rfc3484_sort()
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-12-04 06:52 EST by Fabrice Bellet
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-05 03:28:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 644 None None None Never

  None (edit)
Description Fabrice Bellet 2005-12-04 06:52:46 EST
Description of problem:

The implementation of Rule 9 of the rfc3284 algorithms, should not use ffs() to
obtain the bit-length of the common prefix between a source and destination IP
address, because dotted IPv4 address A.B.C.D  is represented as integer
D<<24+C<<16+B<<8+A on i386, and looking for a common prefix, starting for the
LSB (bit 0) of this integer, refers to bit7 of the network address.

Version-Release number of selected component (if applicable):


How reproducible:

with wget-1.10.2 (that uses getaddrinfo). [wget-1.9.x uses gethostbyname()]

My IP address at home is 82.xx.xx.xx, and when I launch "wget http://rpmfind.net
", it always uses the same IP address, altought rpmfind.net is a round-robin dns
resolving to and, in no specific order. 

When Rule 9 of rfc 3484 searches for the common prefix between 82.xx.xx.xx and
both resolved addresses, it compares bit1=ffs ( 82 ^ 194 ) and bit2=ffs ( 82 ^
195 ) first, around line 1410.

source: 82  = 01010010
dest1:  194 = 11000010
dest2:  195 = 11000011

bit1= 5 (starting comparison from LSB)
bit2= 1 (idem)

The real common network prefix is the same for source ^ dest1 and source ^
dest2, we should have bit1=bit2, so no reordering, and getaddrinfo() shouldn't
change the order returned by the DNS request, but it does in this case.

Note You need to log in before you can comment on or make changes to this bug.