From 050bd7dd0bb089f24325db241a942d1a39559b5d Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Thu, 2 Jun 2005 11:09:10 +0000 Subject: [PATCH] William Ahern: I'm not quite sure how this was happening, but I've been seeing PTR queries which seem to return empty responses. At least, they were empty when calling ares_expand_name() on the record. Here's a patch which guarantees to NUL-terminate the expanded name. The old behavior failed to NUL-terminate if len was 0, and this was causing strlen() to run past the end of the buffer after calling ares_expand_name() and getting ARES_SUCCESS as the return value. If q is not greater than *s then it's equal and *s is always allocated with at least one byte. --- ares/CHANGES | 14 ++++++++++++++ ares/ares_expand_name.c | 2 ++ 2 files changed, 16 insertions(+) diff --git a/ares/CHANGES b/ares/CHANGES index 858804065..cb1fdac24 100644 --- a/ares/CHANGES +++ b/ares/CHANGES @@ -1,5 +1,19 @@ Changelog for the c-ares project +* June 2 + +- William Ahern: + + I'm not quite sure how this was happening, but I've been seeing PTR queries + which seem to return empty responses. At least, they were empty when calling + ares_expand_name() on the record. Here's a patch which guarantees to + NUL-terminate the expanded name. The old behavior failed to NUL-terminate if + len was 0, and this was causing strlen() to run past the end of the buffer + after calling ares_expand_name() and getting ARES_SUCCESS as the return + value. If q is not greater than *s then it's equal and *s is always + allocated with at least one byte. + + * May 16 - Added ares_getnameinfo which mimics the getnameinfo API (another feature diff --git a/ares/ares_expand_name.c b/ares/ares_expand_name.c index 114d0c507..8c5be9b44 100644 --- a/ares/ares_expand_name.c +++ b/ares/ares_expand_name.c @@ -106,6 +106,8 @@ int ares_expand_name(const unsigned char *encoded, const unsigned char *abuf, /* Nuke the trailing period if we wrote one. */ if (q > *s) *(q - 1) = 0; + else + *q = 0; /* zero terminate */ return ARES_SUCCESS; }