Re: [MPTCP][PATCH mptcp-next] Squash to "mptcp: add deny_join_id0 in mptcp_options_received"

[Mat Martineau <mathew.j.martineau@linux.intel.com>]

On Tue, 18 May 2021, Geliang Tang wrote:

> Please add this line to the commit log:
>
> '''
> In mptcp_finish_join, add the incomming join address check too.
> '''
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
> ---
> net/mptcp/protocol.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index c725e8f02533..5cebecc838ca 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -3116,7 +3116,8 @@ bool mptcp_finish_join(struct sock *ssk)
> 	if (!msk->pm.server_side)
> 		goto out;
>
> -	if (!mptcp_pm_allow_new_subflow(msk)) {
> +	if (!mptcp_pm_allow_new_subflow(msk) ||
> +	    (READ_ONCE(msk->pm.remote_deny_join_id0) && !subflow->remote_id)) {

This checks whether this side received a C==1 bit from the remote - but 
that's already checked in mptcp_pm_create_subflow_or_signal_addr().

What might be needed is a check in the opposite direction: if this side 
*sent* C==1, and the incoming MP_JOIN is for the initial addr/port, that's 
invalid.

Not sure yet how we are going to interpret the RFC on this, will be 
discussing at the meeting tomorrow.


> 		subflow->reset_reason = MPTCP_RST_EPROHIBIT;
> 		return false;
> 	}
> -- 
> 2.31.1

--
Mat Martineau
Intel