[PATCH bpf-next v2 02/13] bpf: compare linked-scalar kinds in regs_exact()

[Vineet Gupta <vineet.gupta@linux.dev>]

regs_exact() memcmp()s up to offsetof(id), so it does not see ->add_const,
which sits past ->frameno. Compare it explicitly.

Two cases go from accepted to rejected:

  old {r1.id=A, r2.id=A+delta}  vs cur {r1.id=B, r2.id=B}
  old {r2.id=A+delta32}         vs cur {r2.id=B+delta64}

The first was rejected before this series -- the kind lived in ->id, so
A+delta was a distinct idmap key -- and the previous patch lost that. The
second was accepted before the series too, which is wrong: alu32 and alu64
deltas differ in sync_linked_regs(), so the states are not
interchangeable.

->delta is inside the memcmp() window and is cleared together with the
kind, so either case needs a kind with delta 0, e.g. "r6 = r5; r6 += 0".

Only states_equal(..., EXACT) and env->explore_alu_limits reach
regs_exact() for a scalar; regsafe() compares kinds itself on the ordinary
path. Neither is easy to drive from a test program, so no selftest.

Signed-off-by: Vineet Gupta <vineet.gupta@linux.dev>
---
v2: new. Splits out the comparison RFC 3/6 lost when the kind left
->id, which was raised on that patch.

 kernel/bpf/states.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/bpf/states.c b/kernel/bpf/states.c
index d974baad37ee..5505d7aaeed0 100644
--- a/kernel/bpf/states.c
+++ b/kernel/bpf/states.c
@@ -475,6 +475,7 @@ static bool regs_exact(const struct bpf_reg_state *rold,
 		       struct bpf_idmap *idmap)
 {
 	return memcmp(rold, rcur, offsetof(struct bpf_reg_state, id)) == 0 &&
+	       rold->add_const == rcur->add_const &&
 	       check_ids(rold->id, rcur->id, idmap) &&
 	       check_ids(rold->parent_id, rcur->parent_id, idmap);
 }
-- 
2.53.0-Meta