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.
