All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Maxim Mikityanskiy <maximmi@nvidia.com>,
	bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	netdev@vger.kernel.org
Cc: Tariq Toukan <tariqt@nvidia.com>, Martin KaFai Lau <kafai@fb.com>,
	Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Petar Penkov <ppenkov@google.com>,
	Lorenz Bauer <lmb@cloudflare.com>,
	Eric Dumazet <edumazet@google.com>,
	Maxim Mikityanskiy <maximmi@nvidia.com>
Subject: RE: [PATCH bpf v2 2/4] bpf: Support dual-stack sockets in bpf_tcp_check_syncookie
Date: Mon, 24 Jan 2022 23:04:35 -0800	[thread overview]
Message-ID: <61efa1032e925_274ca208fb@john.notmuch> (raw)
In-Reply-To: <20220124151146.376446-3-maximmi@nvidia.com>

Maxim Mikityanskiy wrote:
> bpf_tcp_gen_syncookie looks at the IP version in the IP header and
> validates the address family of the socket. It supports IPv4 packets in
> AF_INET6 dual-stack sockets.
> 
> On the other hand, bpf_tcp_check_syncookie looks only at the address
> family of the socket, ignoring the real IP version in headers, and
> validates only the packet size. This implementation has some drawbacks:
> 
> 1. Packets are not validated properly, allowing a BPF program to trick
>    bpf_tcp_check_syncookie into handling an IPv6 packet on an IPv4
>    socket.

These programs are all CAP_NET_ADMIN I believe so not so sure this is
critical from a BPF program might trick the helper, but consistency
is nice.

> 
> 2. Dual-stack sockets fail the checks on IPv4 packets. IPv4 clients end
>    up receiving a SYNACK with the cookie, but the following ACK gets
>    dropped.

Agree we need to fix this. Also would be nice to add a test to capture
this case so we don't break it again later. Its a bit subtle so might
not be caught right away without a selftest.

> 
> This patch fixes these issues by changing the checks in
> bpf_tcp_check_syncookie to match the ones in bpf_tcp_gen_syncookie. IP
> version from the header is taken into account, and it is validated
> properly with address family.

Code looks good, would be nice to have a test.

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

> 
> Fixes: 399040847084 ("bpf: add helper to check for a valid SYN cookie")
> Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
> Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
> ---
>  net/core/filter.c | 17 +++++++++++++----

  reply	other threads:[~2022-01-25  8:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-24 15:11 [PATCH bpf v2 0/4] Bugfixes for syncookie BPF helpers Maxim Mikityanskiy
2022-01-24 15:11 ` [PATCH bpf v2 1/4] bpf: Use ipv6_only_sock in bpf_tcp_gen_syncookie Maxim Mikityanskiy
2022-01-25  6:44   ` John Fastabend
2022-01-26  9:46   ` Lorenz Bauer
2022-01-27 21:33     ` Petar Penkov
2022-01-24 15:11 ` [PATCH bpf v2 2/4] bpf: Support dual-stack sockets in bpf_tcp_check_syncookie Maxim Mikityanskiy
2022-01-25  7:04   ` John Fastabend [this message]
2022-01-26  9:49   ` Lorenz Bauer
2022-01-31 13:38     ` Maxim Mikityanskiy
2022-01-24 15:11 ` [PATCH bpf v2 3/4] bpf: Use EOPNOTSUPP " Maxim Mikityanskiy
2022-01-25  7:06   ` John Fastabend
2022-01-31 13:37     ` Maxim Mikityanskiy
2022-01-31 20:55       ` John Fastabend
2022-01-24 15:11 ` [PATCH bpf v2 4/4] bpf: Fix documentation of th_len in bpf_tcp_{gen,check}_syncookie Maxim Mikityanskiy
2022-01-25  7:09   ` John Fastabend
2022-01-26  9:45   ` Lorenz Bauer
2022-01-31 13:37     ` Maxim Mikityanskiy
2022-02-01 17:02       ` Lorenz Bauer
2022-01-25  7:12 ` [PATCH bpf v2 0/4] Bugfixes for syncookie BPF helpers John Fastabend

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=61efa1032e925_274ca208fb@john.notmuch \
    --to=john.fastabend@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=lmb@cloudflare.com \
    --cc=maximmi@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=ppenkov@google.com \
    --cc=songliubraving@fb.com \
    --cc=tariqt@nvidia.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.