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