cURL -- multiple vulnerabilities

cURL reports:

libcurl keeps a pool of its last few connections around
after use to facilitate easy, convenient, and completely
transparent connection re-use for applications.
When doing HTTP requests NTLM authenticated, the entire
connection becomes authenticated and not just the
specific HTTP request which is otherwise how HTTP works.
This makes NTLM special and a subject for special
treatment in the code. With NTLM, once the connection is
authenticated, no further authentication is necessary until
the connection gets closed.

When doing HTTP requests Negotiate authenticated, the
entire connection may become authenticated and not just
the specific HTTP request which is otherwise how HTTP
works, as Negotiate can basically use NTLM under the hood.
curl was not adhering to this fact but would assume that
such requests would also be authenticated per request.

libcurl supports HTTP “cookies” as documented in RFC 6265.
Together with each individual cookie there are several
different properties, but for this vulnerability we
focus on the associated “path” element. It tells
information about for which path on a given host the
cookies is valid.
The internal libcurl function called sanitize_cookie_path()
that cleans up the path element as given to it from a
remote site or when read from a file, did not properly
validate the input. If given a path that consisted of a
single double-quote, libcurl would index a newly
allocated memory area with index -1 and assign a zero
to it, thus destroying heap memory it wasn’t supposed to.

There is a private function in libcurl called fix_hostname()
that removes a trailing dot from the host name if there is
one. The function is called after the host name has been
extracted from the URL libcurl has been told to act on.
If a URL is given with a zero-length host name, like in
“http://:80” or just “:80”, fix_hostname() will index the
host name pointer with a -1 offset (as it blindly assumes
a non-zero length) and both read and assign that address.