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] [day] [month] [year] [list]
Message-ID: <99ed8ee3-f078-873f-6e9a-55b0ef7a2309@iogearbox.net>
Date:   Fri, 3 Dec 2021 21:55:21 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Maxim Mikityanskiy <maximmi@...dia.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Song Liu <songliubraving@...com>,
        KP Singh <kpsingh@...nel.org>,
        John Fastabend <john.fastabend@...il.com>,
        Yonghong Song <yhs@...com>, Martin KaFai Lau <kafai@...com>,
        Andrii Nakryiko <andrii@...nel.org>,
        Shuah Khan <shuah@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        bpf@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH bpf] bpf: Fix the off-by-two error in range markings

On 12/1/21 12:31 PM, Maxim Mikityanskiy wrote:
> On 2021-11-30 23:40, Daniel Borkmann wrote:
>> On 11/30/21 7:16 PM, Maxim Mikityanskiy wrote:
>>> The first commit cited below attempts to fix the off-by-one error that
>>> appeared in some comparisons with an open range. Due to this error,
>>> arithmetically equivalent pieces of code could get different verdicts
>>> from the verifier, for example (pseudocode):
>>>
>>>    // 1. Passes the verifier:
>>>    if (data + 8 > data_end)
>>>        return early
>>>    read *(u64 *)data, i.e. [data; data+7]
>>>
>>>    // 2. Rejected by the verifier (should still pass):
>>>    if (data + 7 >= data_end)
>>>        return early
>>>    read *(u64 *)data, i.e. [data; data+7]
>>>
>>> The attempted fix, however, shifts the range by one in a wrong
>>> direction, so the bug not only remains, but also such piece of code
>>> starts failing in the verifier:
>>>
>>>    // 3. Rejected by the verifier, but the check is stricter than in #1.
>>>    if (data + 8 >= data_end)
>>>        return early
>>>    read *(u64 *)data, i.e. [data; data+7]
>>>
>>> The change performed by that fix converted an off-by-one bug into
>>> off-by-two. The second commit cited below added the BPF selftests
>>> written to ensure than code chunks like #3 are rejected, however,
>>> they should be accepted.
>>>
>>> This commit fixes the off-by-two error by adjusting new_range in the
>>> right direction and fixes the tests by changing the range into the one
>>> that should actually fail.
>>>
>>> Fixes: fb2a311a31d3 ("bpf: fix off by one for range markings with L{T, E} patterns")
>>> Fixes: b37242c773b2 ("bpf: add test cases to bpf selftests to cover all access tests")
>>> Signed-off-by: Maxim Mikityanskiy <maximmi@...dia.com>
>>> ---
>>> After this patch is merged, I'm going to submit another patch to
>>> bpf-next, that will add new selftests for this bug.
>>
>> Thanks for the fix, pls post the selftests for bpf tree; it's okay to route
>> them via bpf so they can go via CI for both trees eventually.
> 
> OK, one question though: if I want to cite the commit hash of this patch in that patch, shall I want till this one is merged and get the commit hash from the bpf tree or should I resubmit them together and just say "previous commit"?

I don't think you strictly need the commit hash, but took this one into bpf right now
since it looks good anyway. Please submit your follow-up selftest patch against bpf tree
as well then.

> Also, I see in patchwork that bpf/vmtest-bpf failed: is it related to my patch or is it something known?

Unrelated bpftool issue:

              bpftool: FAIL (returned 1)
           test_progs: PASS
  test_progs-no_alu32: PASS
            test_maps: PASS
        test_verifier: PASS
  Error: Process completed with exit code 1.

Thanks,
Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ