[Bug libc/515] gethostbyname_r() returns incorrect error for certain sizes (or alignment)

[Bug libc/515] gethostbyname_r() returns incorrect error for certain sizes (or alignment)

[nroche at prologue dot fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=515

Nicolas Roche <nroche at prologue dot fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nroche at prologue dot fr

--- Comment #8 from Nicolas Roche <nroche at prologue dot fr> ---
Created attachment 8424
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8424&action=edit
gethostbyname_r fails: (-1) Resolver internal error

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/515] gethostbyname_r() returns incorrect error for certain sizes (or alignment)

[nroche at prologue dot fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=515

--- Comment #9 from Nicolas Roche <nroche at prologue dot fr> ---
Thank you Guillaume.
So its working for me if I use more or less 512 bytes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/515] gethostbyname_r() returns incorrect error for certain sizes (or alignment)

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2005-10-16 07:54 -------
No reply in 20 days.  Reopen if you reproduce it with modern code.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME


http://sourceware.org/bugzilla/show_bug.cgi?id=515

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

[Bug libc/515] gethostbyname_r() returns incorrect error for certain sizes (or alignment)

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2005-09-26 15:22 -------
I get consistently ret 34 and err -1 for all the sizes I tried.  This is with a
current release.  If you see something else with *current* code say so and
describe how to reproduce it.  Otherwise close the bug.

Also: code using gethostbyname et.al. is broken.  Use getaddrinfo.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=515

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

[Bug libc/515] gethostbyname_r() returns incorrect error for certain sizes (or alignment)

[jamie at shareable dot org]

------- Additional Comments From jamie at shareable dot org  2005-05-09 13:39 -------
A couple more data points:

  1. The buffer size threshold which triggers the bug depends on the length of
the hostname being queried.  Querying for a name with a different length, I
found the threshold varies - with a longer name more likely to trigger the bug.
 That's why it's not clear if there's a guaranteed-safe buffer size.

  2. I've only seen it when resolving a name which resolves through a CNAME.

-- Jamie


-- 


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

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

[Bug libc/515] gethostbyname_r() returns incorrect error for certain sizes (or alignment)

[jamie at shareable dot org]

------- Additional Comments From jamie at shareable dot org  2005-05-09 13:22 -------
Not much code uses gethostbyname_r, and unfortunately the Glibc version has a
bit of a reputation for problems.  (Look in the code for libcurl for comments:
it no longer uses a dynamically allocated buffer, and just uses a large buffer
without resizing now because some older Glibc versions returned EAGAIN instead
of ERANGE when the buffer's too small, and other Glibc versions returned EAGAIN
when a lookup failed...)

Anyway, I just discovered the same bug as being reported here.  With a too-small
buffer, under some circumstances (I found it when resolving CNAMEs over a
certain length, critically dependent on buffer size):

     Glibc-2.3.5 returns:
        ret == EINVAL, errno == EINVAL, *h_errnop == 3 (NO_RECOVERY)

     Glibc-2.3.2-27.9.7 (RH9) returns:
        ret == 0, errno == ERANGE, *h_errnop== 3 (NO_RECOVERY)

Clearly an important bit of code is this from Glibc-2.3.5, nss/getXXbyYY_r.c:

     int res;
     if (status == NSS_STATUS_SUCCESS || status == NSS_STATUS_NOTFOUND)
       res = 0;
     /* Don't pass back ERANGE if this is not for a too-small buffer.  */
     else if (errno == ERANGE && status != NSS_STATUS_TRYAGAIN)
       res = EINVAL;
   #ifdef NEED_H_ERRNO
     /* These functions only set errno if h_errno is NETDB_INTERNAL.  */
     else if (status == NSS_STATUS_TRYAGAIN && *h_errnop != NETDB_INTERNAL)
       res = EAGAIN;
   #endif
     else
       return errno;

     __set_errno (res);
     return res;

The three values, status, errno and *h_errnop, are set in the suspicious code of
glibc/resolv/* and glibc/resolv/nss_dns/*.

Following are some ideas about the resolv/ code for the next person to look at
more closely.

1. In glibc/resolv/nss_dns/dns-network.c, getanswer_r():

          if (errno == EMSGSIZE)
            {
              errno = ERANGE;
              return NSS_STATUS_TRYAGAIN;
            }

   Is it missing an assignment to *h_errnop?

   All the _other_ places in glibc/resolv/nss_dns/*.c which set errno to ERANGE
and return NSS_STATUS_TRYAGAIN do one more thing: They set *h_errnop to
NETDB_INTERNAL.  The above code snipper is not consistent with them.

2. In glibc/resolv/*.c, *h_errnop or h_errno are set to NO_RECOVERY in quite a
lot of places.  Should some of them be non-fatal, setting *h_errnop to
NETDB_INTERNAL, errno to ERANGE, and returning NSS_STATUS_TRYAGAIN?

3. In glibc/resolv/gethnamaddr.c, h_errno is set in quite a lot of places using
__set_h_errno.  Is that appropriate for gethostbyname_r() calls?  The h_errno
value should be stored in *h_errno_p, _not_ in the h_errno variable, right?

Just a few ideas there.  And to add another person to the list who've been stung
by this bug.

One final question: Given the existence of the bug: is there a "safe" buffer
size to use with gethostbyname_r where we can be sure this bug doesn't occur? 
Glibc uses 1024 internally (in gethostbyname) - is that a safe value to use?

-- Jamie

-- 


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

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

[Bug libc/515] gethostbyname_r() returns incorrect error for certain sizes (or alignment)

[gmorin1 at bloomberg dot net]

------- Additional Comments From gmorin1 at bloomberg dot net  2005-02-10 23:16 -------
Any news on that? Are there any showstoppers to fix this bug? I am a bit
surprised I haven't heard anything considering it is a pretty major bug and it
is very easy to reproduce ... Guillaume.

-- 


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

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

[Bug libc/515] gethostbyname_r() returns incorrect error for certain sizes (or alignment)

[guillaume@morinfr.org]

------- Additional Comments From guillaume at morinfr dot org  2004-11-09 02:41 -------
Goto,

I setup a good way to reproduce it on a Debian sid. I got exactly the same
results on a PPC box running 2.6.9 and a x86 one running 2.4.27:

guillaum@siri:~$ tail -1 /etc/hosts
127.0.0.8 foo 0 01 012 0123 01234 012345 0123456 01234567 012345678 0123456789
01234567890 012345678901 012345678901 0123456789012 01234567890123
012345678901234 0123456789012345 01234567890123456 012345678901234567
guillaum@siri:~$ gcc -o foo foo.c -Wall -DBUFFER_SIZE=128 && ./foo
ret is 34, result is (nil), err is -1
error: Numerical result out of range.
guillaum@siri:~$ gcc -o foo foo.c -Wall -DBUFFER_SIZE=256 && ./foo
ret is 22, result is (nil), err is 1
error: Invalid argument.
guillaum@siri:~$ gcc -o foo foo.c -Wall -DBUFFER_SIZE=512 && ./foo
ret is 0, result is 0x7ffff860, err is 1
Success resolving foo. Found aliases:  0 01 012 0123 01234 012345 0123456
01234567 012345678 0123456789 01234567890 012345678901 012345678901
0123456789012 01234567890123 012345678901234 0123456789012345 01234567890123456
012345678901234567
guillaum@siri:~$

This time we get EINVAL for a 256-byte buffer. Afaict this is bogus. The result
is not that different anyway since we're getting err == 1 which is HOST_NOT_FOUND.

HTH.

Guillaume.

-- 


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

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

[Bug libc/515] gethostbyname_r() returns incorrect error for certain sizes (or alignment)

[gmorin1@bloomberg.net]

------- Additional Comments From gmorin1 at bloomberg dot net  2004-11-04 16:36 -------
Created an attachment (id=257)
 --> ( http://sources.redhat.com/bugzilla/attachment.cgi?id=257&action=view )
Test case


-- 


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

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