netdev - Re: [bpf PATCH 9/9] bpf: sockmap/tls, fix pop data with SK

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: <62927807-669A-4917-8A88-DCFAC6A31FA5@flugsvamp.com>
Date:   Thu, 09 Jan 2020 15:28:31 -0800
From:   "Jonathan Lemon" <jlemon@...gsvamp.com>
To:     "John Fastabend" <john.fastabend@...il.com>
Cc:     bpf@...r.kernel.org, netdev@...r.kernel.org, ast@...nel.org,
        daniel@...earbox.net
Subject: Re: [bpf PATCH 9/9] bpf: sockmap/tls, fix pop data with SK_DROP
 return code



On 8 Jan 2020, at 13:16, John Fastabend wrote:

> When user returns SK_DROP we need to reset the number of copied bytes
> to indicate to the user the bytes were dropped and not sent. If we
> don't reset the copied arg sendmsg will return as if those bytes were
> copied giving the user a positive return value.
>
> This works as expected today except in the case where the user also
> pops bytes. In the pop case the sg.size is reduced but we don't correctly
> account for this when copied bytes is reset. The popped bytes are not
> accounted for and we return a small positive value potentially confusing
> the user.
>
> The reason this happens is due to a typo where we do the wrong comparison
> when accounting for pop bytes. In this fix notice the if/else is not
> needed and that we have a similar problem if we push data except its not
> visible to the user because if delta is larger the sg.size we return a
> negative value so it appears as an error regardless.
>
> Fixes: 7246d8ed4dcce ("bpf: helper to pop data from messages")
> Signed-off-by: John Fastabend <john.fastabend@...il.com>
> ---

Acked-by: Jonathan Lemon <jonathan.lemon@...il.com>