netdev - Re: [bpf PATCH] bpf: sockmap, decrement copied count correctly in redirect error case

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: <dd4e700d-d3cc-c2f6-4261-21a4f84b3d08@iogearbox.net>
Date:   Tue, 28 Aug 2018 09:04:46 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     John Fastabend <john.fastabend@...il.com>,
        alexei.starovoitov@...il.com
Cc:     netdev@...r.kernel.org
Subject: Re: [bpf PATCH] bpf: sockmap, decrement copied count correctly in
 redirect error case

On 08/25/2018 02:37 AM, John Fastabend wrote:
> Currently, when a redirect occurs in sockmap and an error occurs in
> the redirect call we unwind the scatterlist once in the error path
> of bpf_tcp_sendmsg_do_redirect() and then again in sendmsg(). Then
> in the error path of sendmsg we decrement the copied count by the
> send size.
> 
> However, its possible we partially sent data before the error was
> generated. This can happen if do_tcp_sendpages() partially sends the
> scatterlist before encountering a memory pressure error. If this
> happens we need to decrement the copied value (the value tracking
> how many bytes were actually sent to TCP stack) by the number of
> remaining bytes _not_ the entire send size. Otherwise we risk
> confusing userspace.
> 
> Also we don't need two calls to free the scatterlist one is
> good enough. So remove the one in bpf_tcp_sendmsg_do_redirect() and
> then properly reduce copied by the number of remaining bytes which
> may in fact be the entire send size if no bytes were sent.
> 
> To do this use bool to indicate if free_start_sg() should do mem
> accounting or not.
> 
> Signed-off-by: John Fastabend <john.fastabend@...il.com>

Applied to bpf, thanks John!