[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6b4b5881-199a-45bf-ade0-7d583ec996e6@nvidia.com>
Date: Wed, 1 Dec 2021 13:31:32 +0200
From: Maxim Mikityanskiy <maximmi@...dia.com>
To: Daniel Borkmann <daniel@...earbox.net>
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 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"?
Also, I see in patchwork that bpf/vmtest-bpf failed: is it related to my
patch or is it something known?
Thanks,
Max
Powered by blists - more mailing lists