netdev - Re: [PATCH net 1/3] bpf: fix off by one for range markings with L{T,E} patterns

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: <0a607e55-3ccb-eab4-f11b-8ef7c9b55c49@gmail.com>
Date:   Sat, 21 Oct 2017 09:39:35 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>, davem@...emloft.net
Cc:     alexei.starovoitov@...il.com, john.r.fastabend@...il.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net 1/3] bpf: fix off by one for range markings with
 L{T,E} patterns

On 10/20/2017 05:34 PM, Daniel Borkmann wrote:
> During review I noticed that the current logic for direct packet
> access marking in check_cond_jmp_op() has an off by one for the
> upper right range border when marking in find_good_pkt_pointers()
> with BPF_JLT and BPF_JLE. It's not really harmful given access
> up to pkt_end is always safe, but we should nevertheless correct
> the range marking before it becomes ABI. If pkt_data' denotes a
> pkt_data derived pointer (pkt_data + X), then for pkt_data' < pkt_end
> in the true branch as well as for pkt_end <= pkt_data' in the false
> branch we mark the range with X although it should really be X - 1
> in these cases. For example, X could be pkt_end - pkt_data, then
> when testing for pkt_data' < pkt_end the verifier simulation cannot
> deduce that a byte load of pkt_data' - 1 would succeed in this
> branch.
> 
> Fixes: b4e432f1000a ("bpf: enable BPF_J{LT, LE, SLT, SLE} opcodes in verifier")
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
> Acked-by: Alexei Starovoitov <ast@...nel.org>
> ---

Acked-by: John Fastabend <john.fastabend@...il.com>