Open jmiltner opened 2 months ago
Please don't report this here: report it to c-ares. We're not going to carry patches to c-ares.
It looks like the issues are already resolved in c-ares latest sources, so this is in fact an issue for this project, as it will need to include a newer version of c-ares to get those problems resolved.
We got the following issues flagged in a Polaris analyzer scan of our source code, which includes swift-async-dns-resolver (version 0.3.1). (The issues are in the imported module c-ares, but since this code is included via swift-async-dns-resolver, we're reporting this here...)
(1) Out-of-bounds access to a buffer in ares__addrinfo2hostent.c:166: This is caused by inconsistent comparison of the "family" variable value against "AF_INET" vs. "AF_INET6".
(2) Dereference after null check in ares_getaddrinfo.c:828: Comparing "hquery->name" to null implies that "hquery->name" might be null. But code continues to dereference "hquery->name" in the for loop stop condition.
(3) Logically dead code in ares_parse_uri_reply.c:155: In line 155, the value of "status" cannot be != ARES_SUCCESS
(4) Logically dead code in ares__readaddrinfo.c:200: In line 200, the value of "status" cannot be != ARES_SUCCESS
(5) Logically dead code in ares_parse_caa_reply.c:169: In line 169, the value of "status" cannot be != ARES_SUCCESS