Re: [PATCH bpf-next v1 2/3] bpf: Compare parent_id in refsafe() for REF_TYPE_PTR

[Eduard Zingerman <eddyz87@gmail.com>]

On Thu, 2026-06-04 at 22:59 +0000, bot+bpf-ci@kernel.org wrote:
> > commit 89f2be9817e074d02702d22068104fb9fd9aa103
> > Author: Amery Hung <ameryhung@gmail.com>
> > Date:   Thu Jun 4 15:09:03 2026 -0700
> > 
> >     bpf: Compare parent_id in refsafe() for REF_TYPE_PTR
> > 
> >     refsafe() compared each reference's id and type but not its parent_id,
> >     so two states whose PTR references differ only in the parent object they
> >     were derived from could be wrongly treated as equivalent and pruned. Fix
> >     it by checking parent_id too.
> > 
> >     Signed-off-by: Amery Hung <ameryhung@gmail.com>
> 
> This looks like a bug fix for parent_id tracking support. Should this
> include:
> 
>   Fixes: 308c7a0ae885 ("bpf: Refactor object relationship tracking and fix dynptr UAF bug")
> 
> When commit 308c7a0ae885 added parent_id tracking, it updated several
> safety-checking functions to compare parent_id but missed adding the
> parent_id check in refsafe() for the REF_TYPE_PTR case. This caused states
> with different parent objects to be incorrectly treated as equivalent
> during state pruning.
> 
> > diff --git a/kernel/bpf/states.c b/kernel/bpf/states.c
> > index 5945956a7573..06d9ae24f006 100644
> > --- a/kernel/bpf/states.c
> > +++ b/kernel/bpf/states.c
> > @@ -890,6 +890,9 @@ static bool refsafe(struct bpf_verifier_state *old, struct bpf_verifier_state *c
> >  			return false;
> >  		switch (old->refs[i].type) {
> >  		case REF_TYPE_PTR:
> > +			if (!check_ids(old->refs[i].parent_id, cur->refs[i].parent_id, idmap))
> > +				return false;
> > +			break;
> >  		case REF_TYPE_IRQ:
> >  			break;
> >  		case REF_TYPE_LOCK:
> 
> This adds an extra check_ids() call for parent_id. Could this make it
> easier to trigger the WARN_ON_ONCE() in check_ids() via BPF_ID_MAP_SIZE
> exhaustion?

I think the bot has the point here. Let's switch to reallocating idmap
or failing check_ids() if there are to many ids (probably an
unrealistic scenario).