From: Charalampos Mitrodimas <charmitro@posteo.net>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>,
Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>,
Feng Yang <yangfeng@kylinos.cn>, Tejun Heo <tj@kernel.org>,
Network Development <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
syzbot+b4169a1cfb945d2ed0ec@syzkaller.appspotmail.com
Subject: Re: [PATCH bpf-next v2] net: Fix RCU usage in task_cls_state() for BPF programs
Date: Wed, 11 Jun 2025 17:07:49 +0000 [thread overview]
Message-ID: <871prqyzoa.fsf@posteo.net> (raw)
In-Reply-To: <CAADnVQJu3fYTfdRTWxeB5hraqe3_Esm7cgKfO38nxodknABeHg@mail.gmail.com>
Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
> On Wed, Jun 11, 2025 at 2:04 AM Charalampos Mitrodimas
> <charmitro@posteo.net> 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, not just networking programs.
>>
>> This helper calls __task_get_classid() which internally calls
>> task_cls_state() requiring rcu_read_lock_bh_held(). This works in
>> networking/tc context where RCU BH is held, but triggers an RCU
>> warning when called from other contexts like BPF syscall programs that
>> 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 also accepting rcu_read_lock_trace_held() as a valid RCU
>> context in the task_cls_state() function. This is safe because BPF
>> programs are non-sleepable and task_cls_state() is only doing an RCU
>> dereference to get the classid.
>>
>> Reported-by: syzbot+b4169a1cfb945d2ed0ec@syzkaller.appspotmail.com
>> 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@posteo.net>
>> ---
>> Changes in v2:
>> - Fix RCU usage in task_cls_state() instead of BPF helper
>> - Add rcu_read_lock_trace_held() check to accept trace RCU as valdi
>> context
>> - Drop the approach of using task_cls_classid() which has in_interrupt()
>> check
>> - Link to v1: https://lore.kernel.org/r/20250608-rcu-fix-task_cls_state-v1-1-2a2025b4603b@posteo.net
>> ---
>> net/core/netclassid_cgroup.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/core/netclassid_cgroup.c b/net/core/netclassid_cgroup.c
>> index d22f0919821e931fbdedf5a8a7a2998d59d73978..df86f82d747ac40e99597d6f2d921e8cc2834e64 100644
>> --- a/net/core/netclassid_cgroup.c
>> +++ b/net/core/netclassid_cgroup.c
>> @@ -21,7 +21,8 @@ static inline struct cgroup_cls_state *css_cls_state(struct cgroup_subsys_state
>> struct cgroup_cls_state *task_cls_state(struct task_struct *p)
>> {
>> return css_cls_state(task_css_check(p, net_cls_cgrp_id,
>> - rcu_read_lock_bh_held()));
>> + rcu_read_lock_bh_held() ||
>> + rcu_read_lock_trace_held()));
>
> This is incomplete. It only addresses one particular syzbot report.
> It needs to include rcu_read_lock_held() as well.
To which other report you are refering to?
>
> pw-bot: cr
next prev parent reply other threads:[~2025-06-11 17:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-11 9:04 Charalampos Mitrodimas
2025-06-11 15:58 ` Alexei Starovoitov
2025-06-11 17:07 ` Charalampos Mitrodimas [this message]
2025-06-11 16:00 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871prqyzoa.fsf@posteo.net \
--to=charmitro@posteo.net \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=haoluo@google.com \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=syzbot+b4169a1cfb945d2ed0ec@syzkaller.appspotmail.com \
--cc=tj@kernel.org \
--cc=yangfeng@kylinos.cn \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®