Bug 473081 - getaddrinfo SEGV on some nis entries
getaddrinfo SEGV on some nis entries
Status: CLOSED DUPLICATE of bug 473073
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-11-26 09:39 EST by Emmanuel Thomé
Modified: 2008-11-27 10:28 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-27 08:00:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
this fix works for me. (3.81 KB, patch)
2008-11-27 10:28 EST, Emmanuel Thomé
no flags Details | Diff

  None (edit)
Description Emmanuel Thomé 2008-11-26 09:39:24 EST
glibc is: glibc-2.9-2.x86_64

The following program aborts with SEGV under circumstances precised below.

#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>

int main()
    struct addrinfo * res = 0x0;
    getaddrinfo ("cups", "631", 0x0, & res);
    return 0;

nsswitch.conf is set up to look for NIS matches. The yp database answers for this query:       hermione.loria.fr hermione serveurcups printserver cups

Note that the failure occurs _only_ for _some_ nis matches (typically those with many aliases).

valgrind says:

==4832== Invalid free() / delete / delete[]
==4832==    at 0x4A0609F: free (vg_replace_malloc.c:323)
==4832==    by 0x5238835: _nss_nis_gethostbyname4_r (nis-hosts.c:537)
==4832==    by 0x3E3C2CD4D5: gaih_inet (getaddrinfo.c:714)
==4832==    by 0x3E3C2CF19C: getaddrinfo (getaddrinfo.c:2154)
==4832==    by 0x4004F3: main (x.c:8)
==4832==  Address 0x4c2f660 is 40 bytes inside a block of size 69 alloc'd
==4832==    at 0x4A0739E: malloc (vg_replace_malloc.c:207)
==4832==    by 0x3E3BA05D5D: yp_match (ypclnt.c:474)
==4832==    by 0x5238739: _nss_nis_gethostbyname4_r (nis-hosts.c:472)
==4832==    by 0x3E3C2CD4D5: gaih_inet (getaddrinfo.c:714)
==4832==    by 0x3E3C2CF19C: getaddrinfo (getaddrinfo.c:2154)
==4832==    by 0x4004F3: main (x.c:8)

Quick inspection shows nothing trivially wrong with the code, at least to my eyes. Stepping the assembly shows that the ``result'' pointer (which eventually goes haywire) is changed by side-effect around the tokenizing call to parse_line.

Prior to parse_line, one has:

3: *$1 = 0x602be0 "\thermione.loria.fr hermione serveurcups printserver cups"

and so, afterwards, result is changed to point to the position of ``serveurcups'' above.

I'm mildly suspecting gcc miscompilation, but I haven't delved into what parse_line exactly does.

Comment 1 Jakub Jelinek 2008-11-27 08:00:41 EST

*** This bug has been marked as a duplicate of bug 473073 ***
Comment 2 Emmanuel Thomé 2008-11-27 08:19:42 EST
(In reply to comment #1)
> *** This bug has been marked as a duplicate of 473073 ***

Quite possibly. However, notice that bug 473073 does not trigger segfault, which I do get with bug 473081.

For 473081, the bug is in parse-list.c in nss/nss_files/files-parse.c ; Buffer overrun on pointer p. I'm probably not the only one working on it at the moment, but I'll come up with a patch later if no one has.

Comment 3 Emmanuel Thomé 2008-11-27 10:28:26 EST
Created attachment 324892 [details]
this fix works for me.

this fixes the following:

- the struct parser_data in gethostbyname4 was putting stuff on the stack
- an off-by-one in the late memcpy
- as an extra safety net, allow for NIS entries with *many* aliases. I've got one out there with more than 128, which overflows parse_list.


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