Re: [PATCH bpf-next v2 1/2] bpf: Invalidate RCU pointers after final spin unlock
"Kumar Kartikeya Dwivedi" <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.bpf |
|---|---|
| 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 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 <[email protected]>
> ---
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!
> [...]