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: <9e49be2a-ec07-4265-a55a-45c1eb19c565@huaweicloud.com>
Date: Tue, 30 Apr 2024 11:56:37 +0800
From: Xu Kuohai <xukuohai@...weicloud.com>
To: Eduard Zingerman <eddyz87@...il.com>,
 Andrii Nakryiko <andrii.nakryiko@...il.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 4/30/2024 6:18 AM, Eduard Zingerman wrote:
> 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?
>

Agree, since 0 is the minimum unsigned number, the result range is
equal to [0, src.u32_max].

>>
>>> +               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.
>>>            */
> 
> [...]