BPF List
 help / color / mirror / Atom feed
From: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
To: "Ning Ding" <dingning04@gmail.com>, <bpf@vger.kernel.org>
Cc: "Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Eduard Zingerman" <eddyz87@gmail.com>,
	"Martin KaFai Lau" <martin.lau@linux.dev>,
	"Song Liu" <song@kernel.org>,
	"Yonghong Song" <yonghong.song@linux.dev>,
	"Jiri Olsa" <jolsa@kernel.org>,
	"Emil Tsalapatis" <emil@etsalapatis.com>,
	"Ihor Solodrai" <ihor.solodrai@linux.dev>,
	"Dave Marchevsky" <davemarchevsky@fb.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next v2 1/2] bpf: Invalidate RCU pointers after final spin unlock
Date: Tue, 04 Aug 2026 11:30:50 +0200	[thread overview]
Message-ID: <DKG1Z3YPOADL.27ICCO5A3JVZO@gmail.com> (raw)
In-Reply-To: <20260803112615.3362122-2-dingning04@gmail.com>

On Mon Aug 3, 2026 at 1:26 PM CEST, Ning Ding wrote:
> In a sleepable BPF program, a spin lock can provide the only RCU protection
> for a kptr. The final bpf_spin_unlock() ends that protection, but the
> verifier leaves the pointer valid. Another CPU can then free the object
> before the pointer is used. A capability-limited runtime PoC triggered a
> task_struct use-after-free in __bpf_get_task_stack().
>
> Record whether the program is in an RCU-protected context before releasing
> the lock. Invalidate RCU-protected pointers only when the unlock leaves the
> final such context. This preserves valid pointers in non-sleepable programs
> and inside an explicit RCU read-side section.
>
> Fixes: 5861d1e8dbc4 ("bpf: Allow bpf_spin_{lock,unlock} in sleepable progs")
> Assisted-by: Codex:gpt-5.6-sol
> Assisted-by: ChatGPT:GPT-5.6-Pro
> Signed-off-by: Ning Ding <dingning04@gmail.com>
> ---

This patch set makes sense. I think while we are at it, we should improve the
behavior here.

For RCU unlock, we currently unconditionally invalidate refs when it hits zero,
even though we may have other sources of RCU protection. The only reason it
doesn't matter right now is probably because we cannot do a RCU read unlock
within a spin lock critical section.

We also do not currently consider bpf_preempt_disable() as providing RCU
protection, even though we should.

Could you extend the series with these changes? And corresponding tests where
possible? It might not be possible for all combinations, but we can test those
that are permitted.

Unlike the correctness fix in this change, these are mostly usability paper
cuts, so do not need a Fixes: tag.

Thanks!

> [...]

  reply	other threads:[~2026-08-04  9:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03 11:26 [PATCH bpf-next v2 0/2] bpf: Invalidate RCU pointers after final spin unlock Ning Ding
2026-08-03 11:26 ` [PATCH bpf-next v2 1/2] " Ning Ding
2026-08-04  9:30   ` Kumar Kartikeya Dwivedi [this message]
2026-08-03 11:26 ` [PATCH bpf-next v2 2/2] selftests/bpf: Test RCU pointer invalidation after " Ning Ding
2026-08-04  9:40 ` [PATCH bpf-next v2 0/2] bpf: Invalidate RCU pointers after final " patchwork-bot+netdevbpf
2026-08-04 10:50 ` Puranjay Mohan

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=DKG1Z3YPOADL.27ICCO5A3JVZO@gmail.com \
    --to=memxor@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davemarchevsky@fb.com \
    --cc=dingning04@gmail.com \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=song@kernel.org \
    --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