Re: [PATCH bpf 0/2] bpf: Preserve rdonly_cast dynptr slice lifetime

[Eduard Zingerman <eddyz87@gmail.com>]

On Mon, 2026-06-15 at 11:40 +0200, Kumar Kartikeya Dwivedi wrote:
> On Mon Jun 15, 2026 at 10:57 AM CEST, Nuoqi Gui wrote:
> > bpf_rdonly_cast() is an identity operation at runtime, but the verifier
> > currently assigns the result fresh return-state metadata. When the source
> > pointer comes from bpf_dynptr_slice(), that drops the relationship needed
> > to invalidate the alias when the dynptr is released.
> > 
> > Preserve the dynptr-slice lifetime metadata across bpf_rdonly_cast(), and
> > add verifier selftests covering cases where a dynptr slice is cast and then
> > read after the dynptr is released or after the originating dynptr stack slot is
> > overwritten while a clone still holds the reference. Also cover the valid clone
> > case where the cast alias is derived from the clone and remains usable after
> > the original dynptr is overwritten.
> > 
> > This fixes regressions introduced by 66e3a13e7c2c ("bpf: Add
> > bpf_dynptr_slice and bpf_dynptr_slice_rdwr") and a35b9af4ec2c ("bpf: Add a
> > kfunc for generic type cast").
> > 
> > Impact is bounded to verifier lifetime tracking for CAP-required BPF
> > programs. The evidence confirms stale read acceptance after dynptr release,
> > including a typed field-read shape, but does not demonstrate unprivileged
> > reachability, cross-context disclosure, controlled reuse, arbitrary kernel
> > read, write-capable aliasing, privilege escalation, crash, or KASAN/UAF
> > signal. No CVE, embargo, or security escalation is claimed.
> > 
> > Validation:
> > - The new dynptr_fail.c subtests exercise the verifier's dynptr-slice
> >   lifetime invariant across bpf_rdonly_cast(): a cast alias of a
> >   bpf_dynptr_slice() result must be invalidated when the dynptr is released or
> >   its stack slot overwritten, while a cast alias derived from a surviving clone
> >   must stay usable.
> 
> Won't fix. The semantics of bpf_rdonly_cast() do not require soruce provenance
> tracking, and thus don't need any invalidation. It can take any unknown value
> and produces safe to read pointer. Please try to reason about whether it's a
> real issue before posting AI's output directly.
> 
> pw-bot: cr

+1, the memory access through untrusted pointers is handled via
prob-read pseudo-instructions. Nothing to fix here.