[PATCH] libbpf hashmap: Fix undefined behavior in hash_bits

[Ian Rogers]

If bits is 0, the case when the map is empty, then the >> is the size of
the register which is undefined behavior - on x86 it is the same as a
shift by 0. Fix by handling the 0 case explicitly when running with
address sanitizer.

A variant of this patch was posted previously as:
https://lore.kernel.org/lkml/20200508063954.256593-1-irogers@xxxxxxxxxx/

Signed-off-by: Ian Rogers <irogers@xxxxxxxxxx>
---
 tools/lib/bpf/hashmap.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/tools/lib/bpf/hashmap.h b/tools/lib/bpf/hashmap.h
index d9b385fe808c..27d0556527d3 100644
--- a/tools/lib/bpf/hashmap.h
+++ b/tools/lib/bpf/hashmap.h
@@ -12,9 +12,23 @@
 #include <stddef.h>
 #include <limits.h>
 
+#ifdef __has_feature
+#define HAVE_FEATURE(f) __has_feature(f)
+#else
+#define HAVE_FEATURE(f) 0
+#endif
+
 static inline size_t hash_bits(size_t h, int bits)
 {
 	/* shuffle bits and return requested number of upper bits */
+#if defined(ADDRESS_SANITIZER) || HAVE_FEATURE(address_sanitizer)
+	/*
+	 * If the requested bits == 0 avoid undefined behavior from a
+	 * greater-than bit width shift right (aka invalid-shift-exponent).
+	 */
+	if (bits == 0)
+		return -1;
+#endif
 #if (__SIZEOF_SIZE_T__ == __SIZEOF_LONG_LONG__)
 	/* LP64 case */
 	return (h * 11400714819323198485llu) >> (__SIZEOF_LONG_LONG__ * 8 - bits);
-- 
2.29.1.341.ge80a0c044ae-goog