All of lore.kernel.org
 help / color / mirror / Atom feed
* [MPTCP] Re: [PATCH net-next v1 4/4] mptcp: handle tcp fallback when using syn cookies
@ 2020-01-28 18:17 Christoph Paasch
  0 siblings, 0 replies; 3+ messages in thread
From: Christoph Paasch @ 2020-01-28 18:17 UTC (permalink / raw)
  To: mptcp

[-- Attachment #1: Type: text/plain, Size: 4441 bytes --]

I just tested this one as well. Works fine now!


Christoph

On 28/01/20 - 16:01:24, Florian Westphal wrote:
> We can't deal with syncookie mode yet, the syncookie rx path will create
> tcp rsk instead of mptcp rsk, i.e. we get OOB access because we treat
> tcp rsk as mptcp rsk:
> 
> TCP: request_sock_subflow: Possible SYN flooding on port 20002. Sending cookies.  Check SNMP counters.
> BUG: KASAN: slab-out-of-bounds in subflow_syn_recv_sock+0x451/0x4d0 net/mptcp/subflow.c:191
> Read of size 1 at addr ffff8881167bc148 by task syz-executor099/2120
>  subflow_syn_recv_sock+0x451/0x4d0 net/mptcp/subflow.c:191
>  tcp_get_cookie_sock+0xcf/0x520 net/ipv4/syncookies.c:209
>  cookie_v6_check+0x15a5/0x1e90 net/ipv6/syncookies.c:252
>  tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1123 [inline]
>  [..]
> 
> Bug can be reproduced via "sysctl net.ipv4.tcp_syncookies=2".
> 
> Note that MPTCP should work with syncookies (4th ack would carry needed
> state), but it appears better to sort that out in -next so do tcp
> fallback for now.
> 
> I decided to remove the ifdef on tcp_rsk "is_mptcp" member because
> if (IS_ENABLED()) is easier to read than "#ifdef IS_ENABLED()/#endif" pair.
> 
> Reported-by: Christoph Paasch <cpaasch(a)apple.com>
> Signed-off-by: Florian Westphal <fw(a)strlen.de>
> ---
>  patch is new in this set.
> 
>  include/linux/tcp.h   | 2 --
>  net/ipv4/syncookies.c | 4 ++++
>  net/ipv4/tcp_input.c  | 3 +++
>  net/ipv6/syncookies.c | 3 +++
>  net/mptcp/subflow.c   | 5 ++++-
>  5 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index 1cf73e6f85ca..3dc964010fef 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -148,9 +148,7 @@ struct tcp_request_sock {
>  	const struct tcp_request_sock_ops *af_specific;
>  	u64				snt_synack; /* first SYNACK sent time */
>  	bool				tfo_listener;
> -#if IS_ENABLED(CONFIG_MPTCP)
>  	bool				is_mptcp;
> -#endif
>  	u32				txhash;
>  	u32				rcv_isn;
>  	u32				snt_isn;
> diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
> index 345b2b0ff618..9a4f6b16c9bc 100644
> --- a/net/ipv4/syncookies.c
> +++ b/net/ipv4/syncookies.c
> @@ -349,6 +349,10 @@ struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb)
>  	req->ts_recent		= tcp_opt.saw_tstamp ? tcp_opt.rcv_tsval : 0;
>  	treq->snt_synack	= 0;
>  	treq->tfo_listener	= false;
> +
> +	if (IS_ENABLED(CONFIG_MPTCP))
> +		treq->is_mptcp = 0;
> +
>  	if (IS_ENABLED(CONFIG_SMC))
>  		ireq->smc_ok = 0;
>  
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index e8b840a4767e..e325b4506e25 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -6637,6 +6637,9 @@ int tcp_conn_request(struct request_sock_ops *rsk_ops,
>  
>  	af_ops->init_req(req, sk, skb);
>  
> +	if (IS_ENABLED(CONFIG_MPTCP) && want_cookie)
> +		tcp_rsk(req)->is_mptcp = 0;
> +
>  	if (security_inet_conn_request(sk, skb, req))
>  		goto drop_and_free;
>  
> diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
> index 30915f6f31e3..13235a012388 100644
> --- a/net/ipv6/syncookies.c
> +++ b/net/ipv6/syncookies.c
> @@ -178,6 +178,9 @@ struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb)
>  	treq = tcp_rsk(req);
>  	treq->tfo_listener = false;
>  
> +	if (IS_ENABLED(CONFIG_MPTCP))
> +		treq->is_mptcp = 0;
> +
>  	if (security_inet_conn_request(sk, skb, req))
>  		goto out_free;
>  
> diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> index 1662e1178949..cf9bad97a12a 100644
> --- a/net/mptcp/subflow.c
> +++ b/net/mptcp/subflow.c
> @@ -186,6 +186,9 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk,
>  
>  	pr_debug("listener=%p, req=%p, conn=%p", listener, req, listener->conn);
>  
> +	if (tcp_rsk(req)->is_mptcp == 0)
> +		goto create_child;
> +
>  	/* if the sk is MP_CAPABLE, we try to fetch the client key */
>  	subflow_req = mptcp_subflow_rsk(req);
>  	if (subflow_req->mp_capable) {
> @@ -767,7 +770,7 @@ static void subflow_ulp_clone(const struct request_sock *req,
>  	struct mptcp_subflow_context *old_ctx = mptcp_subflow_ctx(newsk);
>  	struct mptcp_subflow_context *new_ctx;
>  
> -	if (!subflow_req->mp_capable) {
> +	if (!tcp_rsk(req)->is_mptcp || !subflow_req->mp_capable) {
>  		subflow_ulp_fallback(newsk, old_ctx);
>  		return;
>  	}
> -- 
> 2.24.1
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [MPTCP] Re: [PATCH net-next v1 4/4] mptcp: handle tcp fallback when using syn cookies
@ 2020-01-28 19:48 Florian Westphal
  0 siblings, 0 replies; 3+ messages in thread
From: Florian Westphal @ 2020-01-28 19:48 UTC (permalink / raw)
  To: mptcp

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Matthieu Baerts <matthieu.baerts(a)tessares.net> wrote:
> On 28/01/2020 16:01, Florian Westphal wrote:
> > I decided to remove the ifdef on tcp_rsk "is_mptcp" member because
> > if (IS_ENABLED()) is easier to read than "#ifdef IS_ENABLED()/#endif" pair.
> 
> I agree with you that it is easier to read but will it be OK for upstream?
> Should we use a bitfield and include 'tfo_listener' in it?

It doesn't increase struct size, so I think its OK.  bitfield would be
better but not for -net, we can do this in 2 weeks when net-next opens again.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [MPTCP] Re: [PATCH net-next v1 4/4] mptcp: handle tcp fallback when using syn cookies
@ 2020-01-28 16:41 Matthieu Baerts
  0 siblings, 0 replies; 3+ messages in thread
From: Matthieu Baerts @ 2020-01-28 16:41 UTC (permalink / raw)
  To: mptcp

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

Hi Florian,

On 28/01/2020 16:01, Florian Westphal wrote:
> We can't deal with syncookie mode yet, the syncookie rx path will create
> tcp rsk instead of mptcp rsk, i.e. we get OOB access because we treat
> tcp rsk as mptcp rsk:
> 
> TCP: request_sock_subflow: Possible SYN flooding on port 20002. Sending cookies.  Check SNMP counters.
> BUG: KASAN: slab-out-of-bounds in subflow_syn_recv_sock+0x451/0x4d0 net/mptcp/subflow.c:191
> Read of size 1 at addr ffff8881167bc148 by task syz-executor099/2120
>   subflow_syn_recv_sock+0x451/0x4d0 net/mptcp/subflow.c:191
>   tcp_get_cookie_sock+0xcf/0x520 net/ipv4/syncookies.c:209
>   cookie_v6_check+0x15a5/0x1e90 net/ipv6/syncookies.c:252
>   tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1123 [inline]
>   [..]
> 
> Bug can be reproduced via "sysctl net.ipv4.tcp_syncookies=2".

Thank you for looking at that!

> Note that MPTCP should work with syncookies (4th ack would carry needed
> state), but it appears better to sort that out in -next so do tcp
> fallback for now.

Indeed, it makes sense.

> I decided to remove the ifdef on tcp_rsk "is_mptcp" member because
> if (IS_ENABLED()) is easier to read than "#ifdef IS_ENABLED()/#endif" pair.

I agree with you that it is easier to read but will it be OK for 
upstream? Should we use a bitfield and include 'tfo_listener' in it?

Cheers,
Matt
-- 
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-01-28 19:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-28 18:17 [MPTCP] Re: [PATCH net-next v1 4/4] mptcp: handle tcp fallback when using syn cookies Christoph Paasch
  -- strict thread matches above, loose matches on Subject: below --
2020-01-28 19:48 Florian Westphal
2020-01-28 16:41 Matthieu Baerts

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.