[Bug network/21812] New: getifaddrs() returns entries with ifa_name == NULL

[dalvarez at redhat dot com]

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

            Bug ID: 21812
           Summary: getifaddrs() returns entries with ifa_name == NULL
           Product: glibc
           Version: 2.17
            Status: NEW
          Severity: normal
          Priority: P2
         Component: network
          Assignee: unassigned at sourceware dot org
          Reporter: dalvarez at redhat dot com
  Target Milestone: ---

When getifaddrs tries to retrieve the interface name for an address entry:

- If IFA_LABEL is present in the RTM_NEWADDR message, it grabs it from here [0]
- Else, it will pick it up from the interface [1]: it'll look up the
corresponding interface in the map and grab the name from it.

map_newlink() serves for two purposes: insert a new interface in the map and
lookup an interface from a previously (fully) populated map. In this case,
map_newlink iterates through the map and tries to find the interface whose id
matches the address interface. 

The bug comes when this map is not fully populated, ie., it contains one or
more elements with map[x] == -1 and then, a lookup operation is transformed
into an insert operation and, hence, an "empty" interface is returned.

This will result in this assignment [2] to NULL:

ifas[ifa_index].ifa.ifa_name = ifas[idx].ifa.ifa_name;


I think that the assumption in map_newlink() that the interfaces map shouldn't
contain holes is not correct and it's explicitly advised in the code itself at
[3]:
"/* New Addresses are stored in the order we got them from
    the kernel after the interfaces. Theoretically it is possible
    that we have holes in the interface part of the list,
    but we always have already the interface for this address.  */


The only reason I can see for it to have holes is that kernel is returning more
than one RTM_NEWLINK messages for the same interface and, since we're
allocating memory for as many RTM_NEWLINK messages we received for our request,
then it means that some map entry will be -1 (value to which the map is
initialized).

This has been observed several times running the following versions of glibc
and kernel on a system with more than 500 interfaces which are often added and
removed so situation may be that an interface is added/remove in between
RTM_GETLINK and RTM_GETADDR in getifaddrs_internal()

 glibc.x86_64                    2.17-157.el7_3.1        installed
 kernel.x86_64                   3.10.0-514.6.1.el7
 RHEL 7.3

[0]
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/ifaddrs.c;h=179653103e057b7998a40f814f27a7cee9277845;hb=c758a6861537815c759cba2018a3b1abb1943842#l511
[1]
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/ifaddrs.c;h=179653103e057b7998a40f814f27a7cee9277845;hb=c758a6861537815c759cba2018a3b1abb1943842#l736
[2]
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/ifaddrs.c;h=179653103e057b7998a40f814f27a7cee9277845;hb=c758a6861537815c759cba2018a3b1abb1943842#l742
[3]
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/ifaddrs.c;h=179653103e057b7998a40f814f27a7cee9277845;hb=c758a6861537815c759cba2018a3b1abb1943842#l548

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