Re: [PATCH bpf-next v2 1/2] bpf: Invalidate RCU pointers after final spin unlock

"Kumar Kartikeya Dwivedi" <[email protected]> Tue, 04 Aug 2026 11:30:50 +0200
Newsgroups org.kernel.vger.bpf,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
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 protecti=
on
> 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 releasin=
g
> the lock. Invalidate RCU-protected pointers only when the unlock leaves t=
he
> final such context. This preserves valid pointers in non-sleepable progra=
ms
> and inside an explicit RCU read-side section.
>
> Fixes: 5861d1e8dbc4 ("bpf: Allow bpf_spin_{lock,unlock} in sleepable prog=
s")
> Assisted-by: Codex:gpt-5.6-sol
> Assisted-by: ChatGPT:GPT-5.6-Pro
> Signed-off-by: Ning Ding <[email protected]>
> ---

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

For RCU unlock, we currently unconditionally invalidate refs when it hits z=
ero,
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 whe=
re
possible? It might not be possible for all combinations, but we can test th=
ose
that are permitted.

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

Thanks!

> [...]