[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <12255b55-1d2f-3e4d-128d-770fcdb04c81@solarflare.com>
Date: Tue, 19 Dec 2017 10:29:13 +0000
From: Edward Cree <ecree@...arflare.com>
To: Alexei Starovoitov <ast@...nel.org>,
"David S . Miller" <davem@...emloft.net>
CC: Daniel Borkmann <daniel@...earbox.net>,
Jann Horn <jannh@...gle.com>, <netdev@...r.kernel.org>,
<kernel-team@...com>
Subject: Re: [PATCH bpf 8/9] bpf: fix integer overflows
On 19/12/17 04:12, Alexei Starovoitov wrote:
> Also reduce the scope of "scalar op scalar" tracking.
<snip>
> @@ -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
Powered by blists - more mailing lists