Re: [PATCH bpf-next] bpf: Fix RCU usage in bpf_get_cgroup_classid_curr helper

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jun 8, 2025 at 8:35 AM Charalampos Mitrodimas
<charmitro@xxxxxxxxxx> wrote:
>
> The commit ee971630f20f ("bpf: Allow some trace helpers for all prog
> types") made bpf_get_cgroup_classid_curr helper available to all BPF
> program types.  This helper used __task_get_classid() which calls
> task_cls_state() that requires rcu_read_lock_bh_held().
>
> This triggers an RCU warning when called from BPF syscall programs
> which run under rcu_read_lock_trace():
>
>   WARNING: suspicious RCU usage
>   6.15.0-rc4-syzkaller-g079e5c56a5c4 #0 Not tainted
>   -----------------------------
>   net/core/netclassid_cgroup.c:24 suspicious rcu_dereference_check() usage!
>
> Fix this by replacing __task_get_classid() with task_cls_classid()
> which handles RCU locking internally using regular rcu_read_lock() and
> is safe to call from any context.
>
> Reported-by: syzbot+b4169a1cfb945d2ed0ec@xxxxxxxxxxxxxxxxxxxxxxxxx
> Closes: https://syzkaller.appspot.com/bug?extid=b4169a1cfb945d2ed0ec
> Fixes: ee971630f20f ("bpf: Allow some trace helpers for all prog types")
> Signed-off-by: Charalampos Mitrodimas <charmitro@xxxxxxxxxx>
> ---
>  net/core/filter.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 30e7d36790883b29174654315738e93237e21dd0..3b3f81cf674dde7d2bd83488450edad4e129bdac 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -3083,7 +3083,7 @@ static const struct bpf_func_proto bpf_msg_pop_data_proto = {
>  #ifdef CONFIG_CGROUP_NET_CLASSID
>  BPF_CALL_0(bpf_get_cgroup_classid_curr)
>  {
> -       return __task_get_classid(current);
> +       return task_cls_classid(current);
>  }

Daniel added this helper in
commit 5a52ae4e32a6 ("bpf: Allow to retrieve cgroup v1 classid from v2 hooks")
with intention to use it from networking hooks.

But task_cls_classid() has
        if (in_interrupt())
                return 0;

which will trigger in softirq and tc hooks.
So this might break Daniel's use case.

Daniel,
ptal.





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux