Skip to content

Commit 179d1c5

Browse files
thejhborkmann
authored andcommitted
bpf: don't prune branches when a scalar is replaced with a pointer
This could be made safe by passing through a reference to env and checking for env->allow_ptr_leaks, but it would only work one way and is probably not worth the hassle - not doing it will not directly lead to program rejection. Fixes: f1174f7 ("bpf/verifier: rework value tracking") Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
1 parent a5ec6ae commit 179d1c5

File tree

1 file changed

+7
-8
lines changed

1 file changed

+7
-8
lines changed

kernel/bpf/verifier.c

Lines changed: 7 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -3467,15 +3467,14 @@ static bool regsafe(struct bpf_reg_state *rold, struct bpf_reg_state *rcur,
34673467
return range_within(rold, rcur) &&
34683468
tnum_in(rold->var_off, rcur->var_off);
34693469
} else {
3470-
/* if we knew anything about the old value, we're not
3471-
* equal, because we can't know anything about the
3472-
* scalar value of the pointer in the new value.
3470+
/* We're trying to use a pointer in place of a scalar.
3471+
* Even if the scalar was unbounded, this could lead to
3472+
* pointer leaks because scalars are allowed to leak
3473+
* while pointers are not. We could make this safe in
3474+
* special cases if root is calling us, but it's
3475+
* probably not worth the hassle.
34733476
*/
3474-
return rold->umin_value == 0 &&
3475-
rold->umax_value == U64_MAX &&
3476-
rold->smin_value == S64_MIN &&
3477-
rold->smax_value == S64_MAX &&
3478-
tnum_is_unknown(rold->var_off);
3477+
return false;
34793478
}
34803479
case PTR_TO_MAP_VALUE:
34813480
/* If the new min/max/var_off satisfy the old ones and

0 commit comments

Comments
 (0)