[PATCH bpf 0/9] bpf: verifier security fixes · Alexei Starovoitov <ast@kernel.org> · 2017-12-19
[PATCH bpf 1/9] bpf/verifier: fix bounds calculation on BPF_RSH · Alexei Starovoitov <ast@kernel.org> · 2017-12-19
[PATCH bpf 6/9] bpf: force strict alignment checks for stack pointers · Alexei Starovoitov <ast@kernel.org> · 2017-12-19
[PATCH bpf 4/9] bpf: fix 32-bit ALU op verification · Alexei Starovoitov <ast@kernel.org> · 2017-12-19
[PATCH bpf 3/9] bpf: fix incorrect tracking of register size truncation · Alexei Starovoitov <ast@kernel.org> · 2017-12-19
[PATCH bpf 2/9] bpf: fix incorrect sign extension in check_alu_op() · Alexei Starovoitov <ast@kernel.org> · 2017-12-19
[PATCH bpf 8/9] bpf: fix integer overflows · Alexei Starovoitov <ast@kernel.org> · 2017-12-19
Re: [PATCH bpf 8/9] bpf: fix integer overflows · Edward Cree <hidden> · 2017-12-19
Re: [PATCH bpf 8/9] bpf: fix integer overflows · Alexei Starovoitov <hidden> · 2017-12-19
[PATCH bpf 5/9] bpf: fix missing error return in check_stack_boundary() · Alexei Starovoitov <ast@kernel.org> · 2017-12-19
[PATCH bpf 7/9] bpf: don't prune branches when a scalar is replaced with a pointer · Alexei Starovoitov <ast@kernel.org> · 2017-12-19
[PATCH bpf 9/9] selftests/bpf: add tests for recent bugfixes · Alexei Starovoitov <ast@kernel.org> · 2017-12-19
Re: [PATCH bpf 0/9] bpf: verifier security fixes · Daniel Borkmann <daniel@iogearbox.net> · 2017-12-21

Re: [PATCH bpf 8/9] bpf: fix integer overflows

From: Edward Cree <hidden>
Date: 2017-12-19 10:29:23

On 19/12/17 04:12, Alexei Starovoitov wrote:

Also reduce the scope of "scalar op scalar" tracking.

<snip>

quoted hunk ↗ jump to hunk

@@ -2046,6 +2088,12 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env,
 	src_known = tnum_is_const(src_reg.var_off);
 	dst_known = tnum_is_const(dst_reg->var_off);
 
+	if (!src_known &&
+	    opcode != BPF_ADD && opcode != BPF_SUB && opcode != BPF_AND) {
+		__mark_reg_unknown(dst_reg);
+		return 0;
+	}
+
 	switch (opcode) {
 	case BPF_ADD:
 		if (signed_add_overflows(dst_reg->smin_value, smin_val) ||

Still not seeing any explanation for why this change is necessary.
It also seems arbitrary, e.g. why is AND allowed but not OR?

Hypothetical use case: combining a series of flags based on data read from
 packet into an array index used for storing into a map value.  That sounds
 to me like something someone may be legitimately doing.

-Ed

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help