On Mon, Apr 14, 2025 at 9:14 AM Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote: > > Now that PTR_TO_MEM can be invalidated due to skb going away, we must > take care to be more careful in regsafe regarding state pruning. While > ref_obj_id comparison will ensure that incorrect pruning is prevented, > since we attach ref_obj_id of skb to the PTR_TO_MEM emanating from it, > it is nonetheless clearer to also compare the dynptr_id as well. > > Signed-off-by: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> > --- > kernel/bpf/verifier.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index a62dfab9aea6..7e09c4592038 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -18426,6 +18426,8 @@ static bool regsafe(struct bpf_verifier_env *env, struct bpf_reg_state *rold, > range_within(rold, rcur) && > tnum_in(rold->var_off, rcur->var_off) && > check_ids(rold->id, rcur->id, idmap) && > + (base_type(rold->type) == PTR_TO_MEM ? > + check_ids(rold->dynptr_id, rcur->dynptr_id, idmap) : 1) && > check_ids(rold->ref_obj_id, rcur->ref_obj_id, idmap); hm... shall we split out PTR_TO_MEM case instead of making this not-so-simple condition even more not-so-simple? or (if people don't like that idea), I'd rather have this special PTR_TO_MEM handling as a separate if with return > case PTR_TO_PACKET_META: > case PTR_TO_PACKET: > -- > 2.47.1 >
