From: Hou Tao Date: Wed, 31 Aug 2022 04:26:28 +0000 (+0800) Subject: bpf: Propagate error from htab_lock_bucket() to userspace X-Git-Tag: v6.1-rc5~319^2~251^2~16^2~1 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=66a7a92e4d0d091e79148a4c6ec15d1da65f4280;p=platform%2Fkernel%2Flinux-starfive.git bpf: Propagate error from htab_lock_bucket() to userspace 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. Fixes: 20b6cc34ea74 ("bpf: Avoid hashtab deadlock with map_locked") Reported-by: Hao Sun Signed-off-by: Hou Tao Link: https://lore.kernel.org/r/20220831042629.130006-3-houtao@huaweicloud.com Signed-off-by: Martin KaFai Lau --- diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c index 6fb3b7f..eb1263f 100644 --- a/kernel/bpf/hashtab.c +++ b/kernel/bpf/hashtab.c @@ -1704,8 +1704,11 @@ again_nocopy: /* 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;