netdev - Re: [PATCH bpf-next v3 07/11] bpf: Fix a false rejection caused by AND operation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7cf8b58011156af99816391d3afd5c52e48ea8b7.camel@gmail.com>
Date: Mon, 29 Apr 2024 15:18:25 -0700
From: Eduard Zingerman <eddyz87@...il.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>, Xu Kuohai
	 <xukuohai@...weicloud.com>, Edward Cree <ecree.xilinx@...il.com>
Cc: Yonghong Song <yonghong.song@...ux.dev>, bpf@...r.kernel.org, 
 netdev@...r.kernel.org, linux-security-module@...r.kernel.org, 
 linux-kselftest@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>,
 Andrii Nakryiko <andrii@...nel.org>, Daniel Borkmann
 <daniel@...earbox.net>, Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu
 <song@...nel.org>, John Fastabend <john.fastabend@...il.com>, KP Singh
 <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...gle.com>, Hao Luo
 <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,  Matt Bobrowski
 <mattbobrowski@...gle.com>, Brendan Jackman <jackmanb@...omium.org>, Paul
 Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>, "Serge E .
 Hallyn" <serge@...lyn.com>, Khadija Kamran <kamrankhadijadj@...il.com>,
 Casey Schaufler <casey@...aufler-ca.com>, Ondrej Mosnacek
 <omosnace@...hat.com>, Kees Cook <keescook@...omium.org>, John Johansen
 <john.johansen@...onical.com>, Lukas Bulwahn <lukas.bulwahn@...il.com>,
 Roberto Sassu <roberto.sassu@...wei.com>, Shung-Hsi Yu
 <shung-hsi.yu@...e.com>
Subject: Re: [PATCH bpf-next v3 07/11] bpf: Fix a false rejection caused by
 AND operation

On Mon, 2024-04-29 at 13:58 -0700, Andrii Nakryiko wrote:

[...]

> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 8f0f2e21699e..b69c89bc5cfc 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -13478,6 +13478,28 @@ static void scalar32_min_max_and(struct bpf_reg_state *dst_reg,
> >                  return;
> >          }
> > 
> > +       /* Special case: dst_reg is in range [-1, 0] */
> > +       if (dst_reg->s32_min_value == -1 && dst_reg->s32_max_value == 0) {
> > +               var32_off = tnum_union(src_reg->var_off, tnum_const(0));
> > +               dst_reg->var_off = tnum_with_subreg(dst_reg->var_off, var32_off);
> > +               dst_reg->u32_min_value = var32_off.value;
> > +               dst_reg->u32_max_value = min(dst_reg->u32_max_value, umax_val);
> 
> can you explain the logic behing u32 min/max updates, especially that
> we use completely different values for min/max and it's not clear why
> u32_min <= u32_max invariant will always hold. Same below

I agree with Andrii here.
It appears that dst_reg.{min,max} fields should be set as
{min(src.min, 0), max(src.max, 0)} for both signed and unsigned cases.
Wdyt?

> 
> > +               dst_reg->s32_min_value = min_t(s32, src_reg->s32_min_value, 0);
> > +               dst_reg->s32_max_value = max_t(s32, src_reg->s32_max_value, 0);
> > +               return;
> > +       }
> > +
> > +       /* Special case: src_reg is in range [-1, 0] */
> > +       if (src_reg->s32_min_value == -1 && src_reg->s32_max_value == 0) {
> > +               var32_off = tnum_union(dst_reg->var_off, tnum_const(0));
> > +               dst_reg->var_off = tnum_with_subreg(dst_reg->var_off, var32_off);
> > +               dst_reg->u32_min_value = var32_off.value;
> > +               dst_reg->u32_max_value = min(dst_reg->u32_max_value, umax_val);
> > +               dst_reg->s32_min_value = min_t(s32, dst_reg->s32_min_value, 0);
> > +               dst_reg->s32_max_value = max_t(s32, dst_reg->s32_max_value, 0);
> > +               return;
> > +       }
> > +
> >          /* We get our minimum from the var_off, since that's inherently
> >           * bitwise.  Our maximum is the minimum of the operands' maxima.
> >           */

[...]