Created attachment 6817 [details] 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.
Fixed by d5dd618
Per <http://www.frsag.org/pipermail/frsag/2015-January/005722.html>, CVE-2015-0235 was assigned to this issue.
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
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.
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
*** Bug 19683 has been marked as a duplicate of this bug. ***
This is really great. Wanna keep this for future reference. https://www.toledodeckpros.com