summaryrefslogtreecommitdiff
path: root/crt/x86_64
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2022-10-19 13:15:11 -0400
committerRich Felker <dalias@aerifal.cx>2022-10-19 14:01:32 -0400
commit41603c7706f8a4c1b1a2a23e49ff7490f6860dc2 (patch)
tree776eaac7aee3c08580ab3faafdbffd06c39229f6 /crt/x86_64
parentcf76df0e1fe09b0d504ca650fdaa01df5bf9ab72 (diff)
downloadmusl-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 'crt/x86_64')
0 files changed, 0 insertions, 0 deletions