netdev - Re: [PATCH bpf-next 1/2] bpf: Make remote_port field in struct bpf_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 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]

Date:   Mon, 7 Feb 2022 11:14:42 -0800
From:   Yonghong Song <yhs@...com>
To:     Jakub Sitnicki <jakub@...udflare.com>, <bpf@...r.kernel.org>
CC:     <netdev@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        <kernel-team@...udflare.com>
Subject: Re: [PATCH bpf-next 1/2] bpf: Make remote_port field in struct
 bpf_sk_lookup 16-bit wide



On 2/7/22 5:14 AM, Jakub Sitnicki wrote:
> remote_port is another case of a BPF context field documented as a 32-bit
> value in network byte order for which the BPF context access converter
> generates a load of a zero-padded 16-bit integer in network byte order.
> 
> First such case was dst_port in bpf_sock which got addressed in commit
> 4421a582718a ("bpf: Make dst_port field in struct bpf_sock 16-bit wide").
> 
> Loading 4-bytes from the remote_port offset and converting the value with
> bpf_ntohl() leads to surprising results, as the expected value is shifted
> by 16 bits.
> 
> Reduce the confusion by splitting the field in two - a 16-bit field holding
> a big-endian integer, and a 16-bit zero-padding anonymous field that
> follows it.
> 
> Suggested-by: Alexei Starovoitov <ast@...nel.org>
> Signed-off-by: Jakub Sitnicki <jakub@...udflare.com>

Acked-by: Yonghong Song <yhs@...com>