CVE-2016-7923/Don't assume the target hardware address is <= 6 octets…

… long.

It might not be, either because an unusual hardware type is using ARP or
because a maliciously-constructed packet was sent.  Instead of comparing
against a 6-octet string of zeros with memcmp(), check each octet of the
address against 0.

Fixes a heap overflow found with American Fuzzy Lop by Hanno Böck.

print-arp.c

@@ -177,7 +177,17 @@ struct  atmarp_pkthdr {
 #define ATMTSA(ap) (aar_tsa(ap))
 #define ATMTPA(ap) (aar_tpa(ap))
 
-static u_char ezero[6];
+static int
+isnonzero(const u_char *a, size_t len)
+{
+	while (len > 0) {
+		if (*a != 0)
+			return (1);
+		a++;
+		len--;
+	}
+	return (0);
+}
 
 static void
 atmarp_addr_print(netdissect_options *ndo,
@@ -358,7 +368,7 @@ arp_print(netdissect_options *ndo,
 
 	case ARPOP_REQUEST:
 		ND_PRINT((ndo, "who-has %s", ipaddr_string(ndo, TPA(ap))));
-		if (memcmp((const char *)ezero, (const char *)THA(ap), HRD_LEN(ap)) != 0)
+		if (isnonzero((const u_char *)THA(ap), HRD_LEN(ap)))
 			ND_PRINT((ndo, " (%s)",
 				  linkaddr_string(ndo, THA(ap), linkaddr, HRD_LEN(ap))));
 		ND_PRINT((ndo, " tell %s", ipaddr_string(ndo, SPA(ap))));

tests/TESTLIST

@@ -398,3 +398,4 @@ stp-heapoverflow-2	stp-heapoverflow-2.pcap	stp-heapoverflow-2.out	-t -v -n
 stp-heapoverflow-3	stp-heapoverflow-3.pcap	stp-heapoverflow-3.out	-t -v -n
 stp-heapoverflow-4	stp-heapoverflow-4.pcap	stp-heapoverflow-4.out	-t -v -n
 stp-heapoverflow-5	stp-heapoverflow-5.pcap	stp-heapoverflow-5.out	-t -v -n
+arp-too-long-tha	arp-too-long-tha.pcap	arp-too-long-tha.out	-t -v -n

tests/arp-too-long-tha.out

@@ -0,0 +1 @@
+ARP, Unknown Hardware (12336) (len 14), IPv4 (len 4), Request who-has 48.48.48.48 (30:30:30:30:30:30:30:30:30:30:30:30:30:30) tell 48.48.48.48, length 808464414