glibc-2.9 CVE-2015-7547 fix

[Darcy Watkins]

Hello,

I backported the CVE-2015-7547 fix along with some other related
maintenance to apply to glibc-2.9 and we found that this introduced
regressions handling name lookups in java code running on openjdk7.

Through a bisection-like technique, I managed to isolate it to a single
line of code in the CVE-2015-7547 patch changes applied to
resolv/nss_dns/dns-host.c.

The change adds "*h_errnop = NETDB_INTERNAL;" just before returning
NSS_STATUS_TRYAGAIN to the invoker (in function gaih_getanswer_slice()).

If I comment out that added line (to leave default behaviour for this
case, like before the CVE fix, or if I change the value from
NETDB_INTERNAL to NO_RECOVERY, the regression I noticed appears to be
resolved.

The patch below depicts what I did (for glibc 2.9 after the
CVE-2015-7547 patch has been backported and applied).

--------
diff --git a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c
index c2be74b..a4ba76d 100644
--- a/resolv/nss_dns/dns-host.c
+++ b/resolv/nss_dns/dns-host.c
@@ -1199,7 +1199,11 @@ gaih_getanswer_slice (const querybuf *answer, int anslen, const char *qname,
       return NSS_STATUS_NOTFOUND;
     }
 
+#if 1
+  *h_errnop = NO_RECOVERY;
+#else
   *h_errnop = NETDB_INTERNAL;
+#endif
   return NSS_STATUS_TRYAGAIN;
 }
 
--------


This is the patch chuck from the CVE-2015-7547 patch that it modifies:
--------
--- a/resolv/nss_dns/dns-host.c
+++ b/resolv/nss_dns/dns-host.c
@@ -1190,7 +1193,14 @@ gaih_getanswer_slice (const querybuf *answer, int anslen, const char *qname,
   /* Special case here: if the resolver sent a result but it only
      contains a CNAME while we are looking for a T_A or T_AAAA record,
      we fail with NOTFOUND instead of TRYAGAIN.  */
-  return canon == NULL ? NSS_STATUS_TRYAGAIN : NSS_STATUS_NOTFOUND;
+  if (canon != NULL)
+    {
+      *h_errnop = HOST_NOT_FOUND;
+      return NSS_STATUS_NOTFOUND;
+    }
+
+  *h_errnop = NETDB_INTERNAL;
+  return NSS_STATUS_TRYAGAIN;
 }
 
 
--------

Someone who understands what is going on in this part of the library
please comment to give me some insight, particularly if this change may
be a bad idea for other reasons.

Thanks!

-- 

Regards,

Darcy

---

Darcy Watkins
Staff Engineer, Firmware
Sierra Wireless
13811 Wireless Way, Richmond, BC
Canada, V6V 3A4
[P1]