[Bug network/15014] New: gethostbyname_r() returns EINVAL (22) instead of ERANGE (34)

[Bug network/15014] New: gethostbyname_r() returns EINVAL (22) instead of ERANGE (34)

[peter.klotz99 at gmail dot com]

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

             Bug #: 15014
           Summary: gethostbyname_r() returns EINVAL (22) instead of
                    ERANGE (34)
           Product: glibc
           Version: 2.17
            Status: NEW
          Severity: normal
          Priority: P2
         Component: network
        AssignedTo: unassigned@sourceware.org
        ReportedBy: peter.klotz99@gmail.com
    Classification: Unclassified


Created attachment 6817
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6817
Source that demonstrates the problem

Under certain circumstances gethostbyname_r() returns EINVAL (22) instead of
ERANGE (34).

The attached source demonstrates the problem.

[user@host devel]$ g++ -W -Wall -DDNS_BUFFER_SIZE=37 dnslookup.cpp -o dnslookup
[user@host devel]$ ./dnslookup brain
error: 22 (Unknown resolver error)

[user@host devel]$ g++ -W -Wall -DDNS_BUFFER_SIZE=38 dnslookup.cpp -o dnslookup
[user@host devel]$ ./dnslookup brain

My /etc/hosts file contains this line to resolve host "brain":

10.18.1.19      brain

Using a 37 byte buffer gethostbyname_r() returns EINVAL. With a 38 byte buffer
gethostbyname_r() return ERANGE once, the buffer is doubled and the lookup
succeeds.

I can reproduce this behavior in RHEL5 (glibc 2.5), RHEL6 (glibc 2.12) and Arch
Linux (glibc 2.17) on x86_64.

Is there a minimum size for the buffer to start with? I found nothing in the
manpage.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/15014] gethostbyname_r() returns EINVAL (22) instead of ERANGE (34)

[siddhesh at redhat dot com]

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

Siddhesh Poyarekar <siddhesh at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |siddhesh at redhat dot com
         AssignedTo|unassigned at sourceware    |siddhesh at redhat dot com
                   |dot org                     |

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/15014] gethostbyname_r() returns EINVAL (22) instead of ERANGE (34)

[siddhesh at redhat dot com]

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

Siddhesh Poyarekar <siddhesh at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|siddhesh at redhat dot com  |unassigned at sourceware
                   |                            |dot org

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/15014] gethostbyname_r() returns EINVAL (22) instead of ERANGE (34)

[schwab@linux-m68k.org]

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

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |2.18

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> 2013-05-21 10:57:13 UTC ---
Fixed by d5dd618

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/15014] gethostbyname_r() returns EINVAL (22) instead of ERANGE (34)

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

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

[Bug network/15014] gethostbyname_r() returns EINVAL (22) instead of ERANGE (34) (CVE-2015-0235)

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
            Summary|gethostbyname_r() returns   |gethostbyname_r() returns
                   |EINVAL (22) instead of      |EINVAL (22) instead of
                   |ERANGE (34)                 |ERANGE (34) (CVE-2015-0235)
              Alias|                            |CVE-2015-0235
              Flags|security-                   |security+

--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
Per <http://www.frsag.org/pipermail/frsag/2015-January/005722.html>,
CVE-2015-0235 was assigned to this issue.

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

[Bug network/15014] gethostbyname_r() returns EINVAL (22) instead of ERANGE (34) (CVE-2015-0235)

[lauri.love at gmail dot com]

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

nsh <lauri.love at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lauri.love at gmail dot com

--- Comment #3 from nsh <lauri.love at gmail dot com> ---
Right, obviously this is with all due deference and respect and I hope nobody
takes it the wrong way and thinks I'm being a dick or anything, but: 

Could we take this moment and look back maybe somewhat systematically over
other closed bugs that were deemed of low importance and no security impact
which involved very clearly increasing the size of a buffer so that it becomes
big enough to not get overflowed? 

This could save a lot on a lot of shitty logo design and hot air and generally
silliness in the future...

Best, 
nsh

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

[Bug network/15014] gethostbyname_r() returns EINVAL (22) instead of ERANGE (34) (CVE-2015-0235)

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Florian *has* reviewed over 3000 past glibc bugs for security impact 
(there are a fair number more, mostly older bugs, not yet given a security 
flag), but as this case illustrates it may not be apparent from the bug 
description that a buffer overrun was involved at all (the subject of this 
bug rather suggests a conformance issue with a wrong errno value).

Now, if someone else wants to do their own review of over 3000 bugs with 
"security-" flag, and to query cases where they disagree with that 
assessment, that would be welcome, but probably also very tedious and not 
likely to find many cases of misclassified bugs.

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

[Bug network/15014] gethostbyname_r() returns EINVAL (22) instead of ERANGE (34) (CVE-2015-0235)

[lauri.love at gmail dot com]

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

--- Comment #5 from nsh <lauri.love at gmail dot com> ---
I appreciate that from the bug metadata it's not apparent at all, and (now)
appreciate the work that has been and continues to be put into evaluating
security implications of bugs. In this case, at least, even a trivial grep of
the diff for 'buffer' would flag a mind suitably predisposed towards suspicion.

Could there be some more low-hanging automated patch-analysis fruits? Perhaps
there exists some static analysis tool designed to classify along these lines,
or if not, some more general tool might be specialized to the task. 

I should look into it and try a little myself, I suppose, to see if I'm being
over optimistic about the like reward to invested effort. 

Best, 
nsh

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

[Bug network/15014] gethostbyname_r() returns EINVAL (22) instead of ERANGE (34) (CVE-2015-0235)

[ma.ro.so01234567890 at gmail dot com]

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

Angieng <ma.ro.so01234567890 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ma.ro.so01234567890 at gmail dot c
                   |                            |om

--- Comment #7 from Angieng <ma.ro.so01234567890 at gmail dot com> ---
This is really great. Wanna keep this for future reference. 
https://www.toledodeckpros.com

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