CVE-2015-7547: getaddrinfo() stack-based buffer overflow

[Florian Weimer]

* Mark Andrews:

> And the best way to deal with this is to have manufacturers update
> https://www.kb.cert.org/vuls/id/457759 with their status.  Yes it
> should be a much bigger list than what is there.  Every IoT vendor.
> Every router vendor.  Every OS vendor.  Yes, ISC needs to put in a
> offical status.  If you have a internet connected product and the
> manufacture is not on the list, contact the manufacture and ask
> them to provide a status update.

The real challenge are the vendors who do not realize they are
embedding a copy of glibc in their product.  I'm sure they exist.

> The list may have a lot of "affected if run on a vulnerable OS"
> responses.  For most of these the solution will be "fix the OS,
> relink if statically linked, and reboot the machine".

Static linking is less of a concern, for once.  The reason is that you
need to jump through very special hoops to get a statically linked
copy of nss_dns which uses a statically linked copy of libresolv.
Regular distribution builds for static linking use static dlopen to
dynamically link the required NSS libraries.  Due to some
implementation details, such statically linked binaries are not very
portable between different glibc versions, and there's a clear warning
at static link time that you need the DSOs for the same glibc version
you are statically linking against at run time.