[lwip-devel] [bug #60569] lwip_gethostbyname(_r) does not handle IPv4/IPv6 correctly

[Patrik Lantto]

Follow-up Comment #4, bug #60569 (project lwip):

While lwip_gethostbyname and lwip_gethostbyname_r may of course return
whatever they like in the list of addresses (e.g. an ip_addr_t), the issue is
that LWIP_COMPAT_SOCKETS maps the corresponding POSIX routines, and thus it
should be be expected that they behave the same way.

For the POSIX gethostbyname/gethostbyname_r, hostent returns either a IPv4
address or a IPv6 address. For an IPv4 address, h_addrtype is set to AF_INET,
the address pointers are struct in_addr and h_length would then be sizeof
(struct in_addr).

For IPv6, it is instead AF_INET6, struct in6_addr and sizeof (struct in6_addr)
respectively.

A caller that expects a IPv4 address could copy the address using
'memcpy(dest, hostent->h_addr_list[0], hostent->h_length);'

The way lwip_gethostbyname currently does is that it always sets h_addrtype to
AF_INET (disregarding if it is IPv4 or IPv6), and additionally the length is
set to sizeof (ip_addr_t) which is even longer that in6_addr. Thus any
application expecting to use h_length for the memcpy would corrupt the memory
event if the destination is an in6_addr.

*So I would state the main issue here is that it is not compatible with the
POSIX gethostbyname/gethostbyname_r.*

But an additional sub-issue is that it sets h_addrtype to AF_INET even if the
address would be an IPv6 address (which it may be since netconn_gethostbyname
is used which could return an IPv6 address if IPv4 fails).

The provided patch will still only return AF_INET, but at least it will be
compatible with gethostbyname, and additionally ensure an IPv6 address is
never returned.

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?60569>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/