Re: [PATCH bpf-next v7 07/12] bpf: Optimize word-sized keys for resizable hashtable

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The custom hash function `rhtab_hashfn_long` is vulnerable to Hash Denial of Service (HashDoS) because it fails to mix the random seed non-linearly.
- [High] Directly dereferencing potentially unaligned BPF map key pointers causes unaligned memory access faults.
--

commit 376379c40761f9d44cd7e1638b3ca3a7cb1e989b
Author: Mykyta Yatsenko <yatsenko@meta.com>

bpf: Optimize word-sized keys for resizable hashtable

This commit specializes the lookup, update, and delete paths for BPF resizable
hashtables when the key size matches sizeof(long). It introduces a custom
inline hash and compare function to avoid indirect jhash dispatch.

> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 7b9408b8320c9..b4366cad3cfa5 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -2763,6 +2763,31 @@ static inline void *rhtab_elem_value(struct rhtab_elem *l, u32 key_size)
>  	return l->data + round_up(key_size, 8);
>  }
>  
> +/* Specialize hash function and objcmp for long sized key */
> +static __always_inline int rhtab_key_cmp_long(struct rhashtable_compare_arg *arg,
> +					      const void *ptr)
> +{
> +	const unsigned long key1 = *(const unsigned long *)arg->key;

[Severity: High]
Can this direct pointer dereference cause unaligned access faults on
architectures without hardware support for unaligned loads?

The BPF verifier ensures memory bounds checking for map keys, but does not
enforce that the key pointer is naturally aligned (e.g., keys from packed
structs or packet buffers).

Should this use get_unaligned() to safely read arg->key?

> +	const struct rhtab_elem *key2 = ptr;
> +
> +	return key1 != *(const unsigned long *)key2->data;
> +}
> +
> +static __always_inline u32 rhtab_hashfn_long(const void *data, u32 len, u32 seed)
> +{
> +	u64 k = *(const unsigned long *)data;

[Severity: High]
Can this dereference of the data pointer also cause unaligned access faults,
similar to the key comparison function above?

> +
> +	return (u32)(k ^ (k >> 32)) ^ seed;

[Severity: High]
Does this custom hash function bypass the rhashtable HashDoS mitigation?

Because the random seed is applied via a final linear XOR, the collision
condition for two keys reduces to `(H(k1) & (S - 1)) == (H(k2) & (S - 1))`.
This mathematically makes collisions completely independent of the seed.

If rhashtable's bucket chain length limit is exceeded and it attempts to
rehash with a new random seed, will all colliding keys still map to the exact
same new bucket, causing an infinite rehash loop?

> +}
> +
> +static const struct rhashtable_params rhtab_params_long = {
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605-rhash-v7-0-5b8e05f8630d@meta.com?part=7