Re: [PATCH bpf v2 2/7] bpf: Preserve packet pointer class displacement in regsafe()

[Eduard Zingerman <eddyz87@gmail.com>]

On Sat, 2026-09-05 at 10:34 +0200, Kumar Kartikeya Dwivedi wrote:
> regsafe() maps packet pointer IDs between states and checks that each
> current register range is a subset of the corresponding explored
> register range. It does not, however, preserve the displacement between
> registers that share a packet pointer ID.
> 
> This is unsound because packet range is shared by ID. A bounds check on
> one class member updates every member, and a later access can consume the
> range through another member. Commit 022ac0750883 ("bpf: use reg->var_off
> instead of reg->off for pointers") folded the fixed pointer offset into
> r64 and removed the old off equality check, so two individually narrower
> registers can prune even when their displacement has changed. The
> explored path can then license an out-of-bounds packet access on the
> pruned path.
> 
> Requiring equal r64 bases would prevent the bug, but would also reject a
> safe uniform translation of the whole class. Instead, record the base
> translation seen for the first packet pointer in each ID mapping and
> require every subsequent member to have the same translation. This keeps
> the relative displacement invariant while retaining pruning for uniformly
> translated classes. Packet pointers without an ID remain unaffected.
> 
> Fixes: 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers")
> Reported-by: Nicholas Carlini <npc@anthropic.com>
> Suggested-by: Nicholas Carlini <npc@anthropic.com>
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---

So, essentially this is the same problem as `id + ADD_CONST` tracking
for scalar values, where the actual difference is stored in `delta` field.
In other words, that would be an undo of 022ac0750883 for packet pointers.

What about the original suggested fix:

            /* id relations must be preserved */
            if (!check_ids(rold->id, rcur->id, idmap))
                    return false;
    +       if (rold->id && rold->r64.base != rcur->r64.base)
    +               return false;
            /* new val must satisfy old val knowledge */
            return range_within(rold, rcur) &&
                   tnum_in(rold->var_off, rcur->var_off);

Is it that bad?
Given this logic in adjust_ptr_min_max_vals:

    case BPF_ADD:
        ...
		if (reg_is_pkt_pointer(ptr_reg))
			if (!known)
				dst_reg->id = ++env->id_gen;

I'd expect it to be okay.

...