[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #60569] lwip_gethostbyname(_r) does not handle IPv4/IP
[lwip-devel] [bug #60569] lwip_gethostbyname(_r) does not handle IPv4/IPv6 correctly
Thu, 13 May 2021 14:49:05 -0400 (EDT)
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36 Edg/90.0.818.56
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
For IPv6, it is instead AF_INET6, struct in6_addr and sizeof (struct in6_addr)
A caller that expects a IPv4 address could copy the address using
'memcpy(dest, hostent->h_addr_list, 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
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
Reply to this item at:
Message sent via Savannah