Re: [PATCH v4] bpf: Fix smp_processor_id() call trace for preemptible kernels

[sashiko-bot@kernel.org]

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

New issues:
- [High] Unbounded preempt-disabled loop causes severe scheduling latency and soft lockups.

Pre-existing issues:
- [High] Synchronous freeing of map element fields upon deletion violates RCU reader guarantees, causing Use-After-Free.
--

commit 366a895a5502b13454a28525375f08655dba66d2
Author: Edward Adam Davis <eadavis@qq.com>

bpf: Fix smp_processor_id() call trace for preemptible kernels

This commit attempts to fix a preemption warning in bpf_mem_cache_free_rcu()
by wrapping the batch deletion loop in get_cpu() and put_cpu(). This disables
preemption rather than prohibiting migration.

Link: https://syzkaller.appspot.com/bug?extid=fd7e415d891073b83e1f

> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 9f394e1aa2e85..7b98c2eea6859 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -3345,8 +3345,10 @@ static int __rhtab_map_lookup_and_delete_batch(struct bpf_map *map,
>  	}
>  
>  	if (do_delete) {
> +		get_cpu();
>  		for (i = 0; i < total; i++)
>  			rhtab_delete_elem(rhtab, del_elems[i], NULL, 0);

[Severity: High]
Will this unbounded loop with preemption disabled cause soft lockups?

The user-space process provides the count parameter which determines the size
of the total variable. Wrapping this potentially massive loop inside get_cpu()
and put_cpu() completely disables preemption for the entire duration of the
deletion loop.

Can this lead to severe CPU latency spikes and system unresponsiveness,
especially on real-time and preemptible kernels?

[Severity: High]
This is a pre-existing issue, but does calling rhtab_delete_elem() here
violate RCU reader guarantees?

Looking at rhtab_delete_elem() in kernel/bpf/hashtab.c, it synchronously
frees the element's special fields:

kernel/bpf/hashtab.c:rhtab_delete_elem() {
    ...
    /* Release internal structs: kptr, bpf_timer, task_work, wq */
    rhtab_check_and_free_fields(rhtab, elem);
    bpf_mem_cache_free_rcu(&rhtab->ma, elem);
    return 0;
}

Since rhtab_check_and_free_fields() immediately calls bpf_obj_free_fields(),
this destroys fields (like kptr) before the RCU grace period elapses.

Could concurrent RCU readers accessing the element during the grace period
read freed pointers, resulting in a use-after-free?

> +		put_cpu();
>  	}
>  
>  	rcu_read_unlock();

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_5E4F8F8DADA5DE0DAD924ADD835DD7991707@qq.com?part=1