On Sat, Aug 27, 2022 at 11:43 AM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote:
>
> From: Hou Tao <houtao1@xxxxxxxxxx>
>
> In __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns
> -EBUSY, it will go to next bucket. Going to next bucket may not only
> skip the elements in current bucket silently, but also incur
> out-of-bound memory access or expose kernel memory to userspace if
> current bucket_cnt is greater than bucket_size or zero.
>
> Fixing it by stopping batch operation and returning -EBUSY when
> htab_lock_bucket() fails, and the application can retry or skip the busy
> batch as needed.
>
> Reported-by: Hao Sun <sunhao.th@xxxxxxxxx>
> Signed-off-by: Hou Tao <houtao1@xxxxxxxxxx>
Please add a Fixes tag here
> ---
> kernel/bpf/hashtab.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 6fb3b7fd1622..eb1263f03e9b 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -1704,8 +1704,11 @@ __htab_map_lookup_and_delete_batch(struct bpf_map *map,
> /* do not grab the lock unless need it (bucket_cnt > 0). */
> if (locked) {
> ret = htab_lock_bucket(htab, b, batch, &flags);
> - if (ret)
> - goto next_batch;
> + if (ret) {
> + rcu_read_unlock();
> + bpf_enable_instrumentation();
> + goto after_loop;
> + }
> }
>
> bucket_cnt = 0;
> --
> 2.29.2
>
