netdev - Re: [PATCH net-next v2 5/6] mptcp: support rstreason for passive reset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL+tcoCDTEov0YkeZD7B0v=TQEsfs9LtGiOge71UxUaPzWA9kQ@mail.gmail.com>
Date: Fri, 5 Apr 2024 08:12:55 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Mat Martineau <martineau@...nel.org>
Cc: edumazet@...gle.com, mhiramat@...nel.org, mathieu.desnoyers@...icios.com, 
	rostedt@...dmis.org, kuba@...nel.org, pabeni@...hat.com, davem@...emloft.net, 
	matttbe@...nel.org, geliang@...nel.org, mptcp@...ts.linux.dev, 
	netdev@...r.kernel.org, linux-trace-kernel@...r.kernel.org, 
	Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next v2 5/6] mptcp: support rstreason for passive reset

Hello Mat,

On Fri, Apr 5, 2024 at 4:33 AM Mat Martineau <martineau@...nel.org> wrote:
>
> On Thu, 4 Apr 2024, Jason Xing wrote:
>
> > From: Jason Xing <kernelxing@...cent.com>
> >
> > It relys on what reset options in MPTCP does as rfc8684 says. Reusing
> > this logic can save us much energy. This patch replaces all the prior
> > NOT_SPECIFIED reasons.
> >
> > Signed-off-by: Jason Xing <kernelxing@...cent.com>
> > ---
> > net/mptcp/subflow.c | 26 ++++++++++++++++++++------
> > 1 file changed, 20 insertions(+), 6 deletions(-)
> >
> > diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> > index a68d5d0f3e2a..24668d3020aa 100644
> > --- a/net/mptcp/subflow.c
> > +++ b/net/mptcp/subflow.c
> > @@ -304,7 +304,10 @@ static struct dst_entry *subflow_v4_route_req(const struct sock *sk,
> >
> >       dst_release(dst);
> >       if (!req->syncookie)
> > -             tcp_request_sock_ops.send_reset(sk, skb, SK_RST_REASON_NOT_SPECIFIED);
> > +             /* According to RFC 8684, 3.2. Starting a New Subflow,
> > +              * we should use an "MPTCP specific error" reason code.
> > +              */
> > +             tcp_request_sock_ops.send_reset(sk, skb, SK_RST_REASON_MPTCP_RST_EMPTCP);
>
> Hi Jason -
>
> In this case, the MPTCP reset reason is set in subflow_check_req(). Looks
> like it uses EMPTCP but that isn't guaranteed to stay the same. I think it
> would be better to extract the reset reason from the skb extension or the
> subflow context "reset_reason" field.

Good suggestions :)

>
>
> >       return NULL;
> > }
> >
> > @@ -371,7 +374,10 @@ static struct dst_entry *subflow_v6_route_req(const struct sock *sk,
> >
> >       dst_release(dst);
> >       if (!req->syncookie)
> > -             tcp6_request_sock_ops.send_reset(sk, skb, SK_RST_REASON_NOT_SPECIFIED);
> > +             /* According to RFC 8684, 3.2. Starting a New Subflow,
> > +              * we should use an "MPTCP specific error" reason code.
> > +              */
> > +             tcp6_request_sock_ops.send_reset(sk, skb, SK_RST_REASON_MPTCP_RST_EMPTCP);
>
> Same issue here.

Got it.

>
> >       return NULL;
> > }
> > #endif
> > @@ -778,6 +784,7 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk,
> >       bool fallback, fallback_is_fatal;
> >       struct mptcp_sock *owner;
> >       struct sock *child;
> > +     int reason;
> >
> >       pr_debug("listener=%p, req=%p, conn=%p", listener, req, listener->conn);
> >
> > @@ -833,7 +840,8 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk,
> >                */
> >               if (!ctx || fallback) {
> >                       if (fallback_is_fatal) {
> > -                             subflow_add_reset_reason(skb, MPTCP_RST_EMPTCP);
> > +                             reason = MPTCP_RST_EMPTCP;
> > +                             subflow_add_reset_reason(skb, reason);
> >                               goto dispose_child;
> >                       }
> >                       goto fallback;
> > @@ -861,7 +869,8 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk,
> >               } else if (ctx->mp_join) {
> >                       owner = subflow_req->msk;
> >                       if (!owner) {
> > -                             subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT);
> > +                             reason = MPTCP_RST_EPROHIBIT;
> > +                             subflow_add_reset_reason(skb, reason);
> >                               goto dispose_child;
> >                       }
> >
> > @@ -875,13 +884,18 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk,
> >                                        ntohs(inet_sk((struct sock *)owner)->inet_sport));
> >                               if (!mptcp_pm_sport_in_anno_list(owner, sk)) {
> >                                       SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_MISMATCHPORTACKRX);
> > +                                     reason = MPTCP_RST_EUNSPEC;
>
> I think the MPTCP code here should have been using MPTCP_RST_EPROHIBIT.

I'll update in the V2 of the patch.

Thanks,
Jason