Re: [PATCH bpf 1/2] bpf: bound resizable hash map iteration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The iteration budget `map->max_entries` is insufficient to prevent severe RCU stalls because RHASH maps decouple `max_entries` from memory constraints.
--

commit e7196eb4e04d6b29df6a798ca5bcbe264c41d6e2
Author: Hui Su <sh_def@163.com>

bpf: bound resizable hash map iteration

This patch attempts to fix an unbounded iteration loop in bpf_each_rhash_elem
by using map->max_entries as an iteration budget. Duplicate visits consume the
budget to ensure termination under concurrent mutations.

> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index d40cb5dd446ca..3772e63f2f12f 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c

[ ... ]

> @@ -3212,7 +3212,8 @@ static long bpf_each_rhash_elem(struct bpf_map *map, bpf_callback_t callback_fn,
>  	 * elements are deleted/inserted, there may be missed or duplicate
>  	 * elements visited.
>  	 */
> -	while ((elem = rhashtable_next_key(&rhtab->ht, prev_key))) {
> +	while (num_elems < map->max_entries &&
> +	       (elem = rhashtable_next_key(&rhtab->ht, prev_key))) {

[Severity: High]
This is a pre-existing issue, but will this bound be sufficient to prevent
RCU stalls if max_entries is set to its maximum limit?

For a BPF_MAP_TYPE_RHASH map, max_entries can be up to 1UL << 31 
(2.14 billion) because the map requires BPF_F_NO_PREALLOC. This decouples 
max_entries from memory constraints, meaning a user can instantly create a 
map with the maximum limit using negligible memory.

If a user invokes the bpf_for_each_map_elem helper on this map while
concurrently mutating it from user space, the loop could repeatedly yield
duplicate elements.

Executing this callback 2.14 billion times inside an rcu_read_lock section 
without cond_resched() will still take dozens of seconds. This easily 
eclipses the standard 21-second RCU stall or 20-second soft lockup 
thresholds, allowing a Denial of Service.

Could a smaller, fixed iteration limit or a time-based check be used here 
instead to ensure the loop terminates before a stall occurs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828183326.3330530-1-sh_def@163.com?part=1