diff options
author | Rich Felker <dalias@aerifal.cx> | 2022-10-19 13:15:11 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2022-10-19 14:01:32 -0400 |
commit | 41603c7706f8a4c1b1a2a23e49ff7490f6860dc2 (patch) | |
tree | 776eaac7aee3c08580ab3faafdbffd06c39229f6 /src/stdio/flockfile.c | |
parent | cf76df0e1fe09b0d504ca650fdaa01df5bf9ab72 (diff) | |
download | musl-41603c7706f8a4c1b1a2a23e49ff7490f6860dc2.tar.gz musl-41603c7706f8a4c1b1a2a23e49ff7490f6860dc2.tar.bz2 musl-41603c7706f8a4c1b1a2a23e49ff7490f6860dc2.tar.xz musl-41603c7706f8a4c1b1a2a23e49ff7490f6860dc2.zip |
dns response handling: ignore presence of wrong-type RRs
reportedly there is nameserver software with question-rewriting
"functionality" which gives A answers when AAAA is queried. since we
made no effort to validate that the answer RR type actually
corresponds to the question asked, it was possible (depending on
flags, etc.) for these answers to leak through, which the caller might
not be prepared for. indeed, our implementation of gethostbyname2_r
makes an assumption that the resulting addresses are in the family
requested, and will misinterpret the results if they don't.
commit 45ca5d3fcb6f874bf5ba55d0e9651cef68515395 already noted in
fixing CVE-2017-15650 that this could happen, but did nothing to
validate that the RR type of the answer matches the question; it just
enforced the limit on number of results to preclude overflow.
presently, name_from_dns ignores the return value of __dns_parse, so
it doesn't really matter whether we return 0 (ignoring the RR) or -1
(parse-ending error) upon encountering the mismatched RR. if that ever
changes, though, ignoring irrelevant answer RRs sounds like the
semantically correct thing to do, so for now let's return 0 from the
callback when this happens.
Diffstat (limited to 'src/stdio/flockfile.c')
0 files changed, 0 insertions, 0 deletions