public inbox for dccp@vger.kernel.org
 help / color / mirror / Atom feed
From: Mat Martineau <mathew.j.martineau@linux.intel.com>
To: dccp@vger.kernel.org
Subject: Re: [PATCH net] ipv6: weaken the v4mapped source check
Date: Wed, 17 Mar 2021 22:58:54 +0000	[thread overview]
Message-ID: <b5f2f124-cdd1-ce9a-49e-878ad45d385@linux.intel.com> (raw)
In-Reply-To: <20210317165515.1914146-1-kuba@kernel.org>


On Wed, 17 Mar 2021, Jakub Kicinski wrote:

> This reverts commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3.
>
> Commit 6af1799aaf3f ("ipv6: drop incoming packets having a v4mapped
> source address") introduced an input check against v4mapped addresses.
> Use of such addresses on the wire is indeed questionable and not
> allowed on public Internet. As the commit pointed out
>
>  https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02
>
> lists potential issues.
>
> Unfortunately there are applications which use v4mapped addresses,
> and breaking them is a clear regression. For example v4mapped
> addresses (or any semi-valid addresses, really) may be used
> for uni-direction event streams or packet export.
>
> Since the issue which sparked the addition of the check was with
> TCP and request_socks in particular push the check down to TCPv6
> and DCCP. This restores the ability to receive UDPv6 packets with
> v4mapped address as the source.
>
> Keep using the IPSTATS_MIB_INHDRERRORS statistic to minimize the
> user-visible changes.
>
> Fixes: 6af1799aaf3f ("ipv6: drop incoming packets having a v4mapped source address")
> Reported-by: Sunyi Shao <sunyishao@fb.com>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> net/dccp/ipv6.c      |  5 +++++
> net/ipv6/ip6_input.c | 10 ----------
> net/ipv6/tcp_ipv6.c  |  5 +++++
> net/mptcp/subflow.c  |  5 +++++
> 4 files changed, 15 insertions(+), 10 deletions(-)

Jakub -

Thanks for keeping the MPTCP code in sync. The IPv6 and v4mapped MPTCP 
selftests still pass. For the MPTCP content:

Acked-by: Mat Martineau <mathew.j.martineau@linux.intel.com>


>
> diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
> index 1f73603913f5..2be5c69824f9 100644
> --- a/net/dccp/ipv6.c
> +++ b/net/dccp/ipv6.c
> @@ -319,6 +319,11 @@ static int dccp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
> 	if (!ipv6_unicast_destination(skb))
> 		return 0;	/* discard, don't send a reset here */
>
> +	if (ipv6_addr_v4mapped(&ipv6_hdr(skb)->saddr)) {
> +		__IP6_INC_STATS(sock_net(sk), NULL, IPSTATS_MIB_INHDRERRORS);
> +		return 0;
> +	}
> +
> 	if (dccp_bad_service_code(sk, service)) {
> 		dcb->dccpd_reset_code = DCCP_RESET_CODE_BAD_SERVICE_CODE;
> 		goto drop;
> diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
> index e9d2a4a409aa..80256717868e 100644
> --- a/net/ipv6/ip6_input.c
> +++ b/net/ipv6/ip6_input.c
> @@ -245,16 +245,6 @@ static struct sk_buff *ip6_rcv_core(struct sk_buff *skb, struct net_device *dev,
> 	if (ipv6_addr_is_multicast(&hdr->saddr))
> 		goto err;
>
> -	/* While RFC4291 is not explicit about v4mapped addresses
> -	 * in IPv6 headers, it seems clear linux dual-stack
> -	 * model can not deal properly with these.
> -	 * Security models could be fooled by ::ffff:127.0.0.1 for example.
> -	 *
> -	 * https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02
> -	 */
> -	if (ipv6_addr_v4mapped(&hdr->saddr))
> -		goto err;
> -
> 	skb->transport_header = skb->network_header + sizeof(*hdr);
> 	IP6CB(skb)->nhoff = offsetof(struct ipv6hdr, nexthdr);
>
> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> index bd44ded7e50c..d0f007741e8e 100644
> --- a/net/ipv6/tcp_ipv6.c
> +++ b/net/ipv6/tcp_ipv6.c
> @@ -1175,6 +1175,11 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
> 	if (!ipv6_unicast_destination(skb))
> 		goto drop;
>
> +	if (ipv6_addr_v4mapped(&ipv6_hdr(skb)->saddr)) {
> +		__IP6_INC_STATS(sock_net(sk), NULL, IPSTATS_MIB_INHDRERRORS);
> +		return 0;
> +	}
> +
> 	return tcp_conn_request(&tcp6_request_sock_ops,
> 				&tcp_request_sock_ipv6_ops, sk, skb);
>
> diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> index 3d47d670e665..d17d39ccdf34 100644
> --- a/net/mptcp/subflow.c
> +++ b/net/mptcp/subflow.c
> @@ -477,6 +477,11 @@ static int subflow_v6_conn_request(struct sock *sk, struct sk_buff *skb)
> 	if (!ipv6_unicast_destination(skb))
> 		goto drop;
>
> +	if (ipv6_addr_v4mapped(&ipv6_hdr(skb)->saddr)) {
> +		__IP6_INC_STATS(sock_net(sk), NULL, IPSTATS_MIB_INHDRERRORS);
> +		return 0;
> +	}
> +
> 	return tcp_conn_request(&mptcp_subflow_request_sock_ops,
> 				&subflow_request_sock_ipv6_ops, sk, skb);
>
> -- 
> 2.30.2

--
Mat Martineau
Intel

  reply	other threads:[~2021-03-17 22:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17 16:55 [PATCH net] ipv6: weaken the v4mapped source check Jakub Kicinski
2021-03-17 22:58 ` Mat Martineau [this message]
2021-03-18  9:45 ` Eric Dumazet
2021-03-18 18:30 ` patchwork-bot+netdevbpf

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=b5f2f124-cdd1-ce9a-49e-878ad45d385@linux.intel.com \
    --to=mathew.j.martineau@linux.intel.com \
    --cc=dccp@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox