As promised in #2970, this attempts to migrate code to a common set of
utilities in a common place in the code and use them everywhere. This
also exports the functionality, since the Windows API with
WideCharToMultiByte is fairly verbose relative to what libuv and
libuv's clients typically need, so it is useful not to require clients
to reimplement this conversion logic unnecessarily (and because Windows
is not 64-bit ready here, but this implementation is.)
Switch from old-style ASSERT macro to new-style ASSERT_EQ,... macros.
Using new-style macros makes it easier to debug test failures
Fixes: https://github.com/libuv/libuv/issues/2974
```
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
note: in expansion of macro 'ASSERT_BASE'
#define ASSERT_EQ(a, b) ASSERT_BASE(a, ==, b, int64_t, PRId64)
warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but
argument 3 has type ‘uint32_t’ {aka ‘unsigned int’}
```
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
libuv was vulnerable to out-of-bounds reads in the uv__idna_toascii()
function which is used to convert strings to ASCII. This is called by
the DNS resolution function and can lead to information disclosures or
crashes.
Reported by Eric Sesterhenn in collaboration with Cure53 and ExpressVPN.
Reported-By: Eric Sesterhenn <eric.sesterhenn@x41-dsec.de>
Fixes: https://github.com/libuv/libuv/issues/3147
PR-URL: https://github.com/libuv/libuv-private/pull/1
Refs: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22918
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Encode domain names before passing them on to the libc resolver.
Some getaddrinfo() implementations support IDNA 2008, some only
IDNA 2003 and some don't support i18n domain names at all.
This is a potential security issue because it means a domain name
might resolve differently depending on the system that libuv is
running on.
Fixes: https://github.com/libuv/libuv/issues/2028
PR-URL: https://github.com/libuv/libuv/pull/2046
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
