lwIP - A Lightweight TCP/IP stack - Bugs: bug #60569, lwip_gethostbyname(_r) does not...
You are not allowed to post comments on this tracker with your current authentication level.
bug #60569: lwip_gethostbyname(_r) does not handle IPv4/IPv6 correctly
Submitter: | Patrik Lantto <patriklantto> | ||
Submitted: | Mon 10 May 2021 07:27:17 AM UTC | ||
Category: | DNS | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | Planned Release: | None |
lwIP version: | git head |
Wed 26 May 2021 06:45:02 AM UTC, comment #5: |
Patrik Lantto <patriklantto> |
Thu 13 May 2021 06:49:05 PM UTC, comment #4: 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.
|
Patrik Lantto <patriklantto> |
Thu 13 May 2021 11:21:53 AM UTC, comment #3: Maybe one case where it could be a problem is a v4 only build resolving a hostname only return a v6 address? Not sure if that is supported. |
Erik Ekman <yarrick>![]() |
Thu 13 May 2021 11:20:17 AM UTC, comment #2: ip_addr_t is sized to fit any IP address supported in the build - so there should not be any out of bounds writes at least. Did you see memory corruption happen?
|
Erik Ekman <yarrick>![]() |
Tue 11 May 2021 07:46:33 AM UTC, comment #1: Patch to correct behaviour of gethostbyname() and gethostbyname_r() for AF_INET has been attached. |
Patrik Lantto <patriklantto> |
Mon 10 May 2021 07:27:17 AM UTC, original submission:
lwip_gethostbyname and lwip_gethostbyname_r are currently always setting the h_addrtype field of struct hostent to AF_INET disregarding if the result is IPv4 or IPv6. Moreover, the h_length field is set to sizeof (ip_addr_t) instead of sizeof (struct in_addr) or sizeof (struct in6_addr) respectively. An application that uses the h_length field to copy the adress would potentially corrupt memory; the amount of corrupted bytes depends on whether lwIP is compiled with IPv6 support or not.
|
Patrik Lantto <patriklantto> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2021-05-26 | patriklantto | Attached File | - | ![]() |
Added 60569-gethostbyname2.patch, #51481 |
2021-05-11 | patriklantto | Attached File | - | ![]() |
Added 60569-gethostbyname.patch, #51417 |
As there has not been any further response on this topic, I can only assume there is some hesitation on applying the patch without the support for IPv6 (even though the previous version hardcoded the h_addrtype to AF_INET).
I have now updated the patch so that lwip_gethostbyname and lwip_gethostbyname_r supports AF_INET and AF_INET6, and correctly sets h_addrtype, h_length and the h_addr_list entry accordingly (i.e. AF_INET/struct in_addr and AF_INET6/struct in6_addr respectively).
In addition I have also added two routines lwip_gethostbyname2 and lwip_gethostbyname2_r corresponding to the glibc2 routines gethostbyname2 and gethostbyname2_r. There routines permits to specify the address family. For a caller that do not expect gethostbyname to support AF_INET6, the compatibility layer can now choose to define gethostbyname as lwip_gethostbyname2 and specify AF_INET.
While updating the implementation, I made one common “helper” routine that the four other routines are calling, and additionally corrected a somewhat strange usage of the memory alignment that could cause lwip_gethostbyname_r to return ERANGE even if the buffer was large enough.
New patch is attached.
(file #51481)