All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Mikityanskiy <maximmi@nvidia.com>
To: Lorenz Bauer <lmb@cloudflare.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Networking <netdev@vger.kernel.org>,
	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>,
	Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH bpf v2 2/4] bpf: Support dual-stack sockets in bpf_tcp_check_syncookie
Date: Mon, 31 Jan 2022 15:38:12 +0200	[thread overview]
Message-ID: <727ed7f4-c29e-05e1-2d8d-2f1dcdd06002@nvidia.com> (raw)
In-Reply-To: <CACAyw9_mA-yBWbU6Sf8hq6P46PfiTpEZYTGSKmNG6ZiFWGz=ZQ@mail.gmail.com>

On 2022-01-26 11:49, Lorenz Bauer wrote:
> On Mon, 24 Jan 2022 at 15:13, Maxim Mikityanskiy <maximmi@nvidia.com> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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 +++++++++++++----
>>   1 file changed, 13 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/core/filter.c b/net/core/filter.c
>> index 05efa691b796..780e635fb52a 100644
>> --- a/net/core/filter.c
>> +++ b/net/core/filter.c
>> @@ -6774,24 +6774,33 @@ BPF_CALL_5(bpf_tcp_check_syncookie, struct sock *, sk, void *, iph, u32, iph_len
>>          if (!th->ack || th->rst || th->syn)
>>                  return -ENOENT;
>>
>> +       if (unlikely(iph_len < sizeof(struct iphdr)))
>> +               return -EINVAL;
>> +
>>          if (tcp_synq_no_recent_overflow(sk))
>>                  return -ENOENT;
>>
>>          cookie = ntohl(th->ack_seq) - 1;
>>
>> -       switch (sk->sk_family) {
>> -       case AF_INET:
>> -               if (unlikely(iph_len < sizeof(struct iphdr)))
>> +       /* Both struct iphdr and struct ipv6hdr have the version field at the
>> +        * same offset so we can cast to the shorter header (struct iphdr).
>> +        */
>> +       switch (((struct iphdr *)iph)->version) {
>> +       case 4:
>> +               if (sk->sk_family == AF_INET6 && ipv6_only_sock(sk))
>>                          return -EINVAL;
> 
> Wouldn't this allow an arbitrary value for sk->sk_family, since there
> is no further check that sk_family is AF_INET?

It relies on the assumption that sk_family is either AF_INET or 
AF_INET6, when sk_protocol is IPPROTO_TCP (checked above). The same 
assumption is used in bpf_tcp_gen_syncookie. Do you think there are 
cases when it doesn't hold, and we must verify sk_family? If yes, then 
bpf_tcp_gen_syncookie should also be fixed.

  reply	other threads:[~2022-01-31 13:38 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
2022-01-26  9:49   ` Lorenz Bauer
2022-01-31 13:38     ` Maxim Mikityanskiy [this message]
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=727ed7f4-c29e-05e1-2d8d-2f1dcdd06002@nvidia.com \
    --to=maximmi@nvidia.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=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=lmb@cloudflare.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.