From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omzsmtpe01.verizonbusiness.com ([199.249.25.210]:63682 "EHLO omzsmtpe01.verizonbusiness.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754631AbdDDTdB (ORCPT ); Tue, 4 Apr 2017 15:33:01 -0400 From: alexander.levin@verizon.com To: "gregkh@linuxfoundation.org" CC: "stable@vger.kernel.org" Subject: [PATCH for 4.9 16/98] svcauth_gss: Close connection when dropping an incoming message Date: Tue, 4 Apr 2017 19:32:07 +0000 Message-ID: <20170404193158.19041-17-alexander.levin@verizon.com> References: <20170404193158.19041-1-alexander.levin@verizon.com> In-Reply-To: <20170404193158.19041-1-alexander.levin@verizon.com> Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org List-ID: From: Chuck Lever [ Upstream commit 4d712ef1db05c3aa5c3b690a50c37ebad584c53f ] S5.3.3.1 of RFC 2203 requires that an incoming GSS-wrapped message whose sequence number lies outside the current window is dropped. The rationale is: The reason for discarding requests silently is that the server is unable to determine if the duplicate or out of range request was due to a sequencing problem in the client, network, or the operating system, or due to some quirk in routing, or a replay attack by an intruder. Discarding the request allows the client to recover after timing out, if indeed the duplication was unintentional or well intended. However, clients may rely on the server dropping the connection to indicate that a retransmit is needed. Without a connection reset, a client can wait forever without retransmitting, and the workload just stops dead. I've reproduced this behavior by running xfstests generic/323 on an NFSv4.0 mount with proto=3Drdma and sec=3Dkrb5i. To address this issue, have the server close the connection when it silently discards an incoming message due to a GSS sequence number problem. There are a few other places where the server will never reply. Change those spots in a similar fashion. Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin --- net/sunrpc/auth_gss/svcauth_gss.c | 2 +- net/sunrpc/svc.c | 14 +++++++++----- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcaut= h_gss.c index 6fdffde..1530825 100644 --- a/net/sunrpc/auth_gss/svcauth_gss.c +++ b/net/sunrpc/auth_gss/svcauth_gss.c @@ -1548,7 +1548,7 @@ svcauth_gss_accept(struct svc_rqst *rqstp, __be32 *au= thp) ret =3D SVC_COMPLETE; goto out; drop: - ret =3D SVC_DROP; + ret =3D SVC_CLOSE; out: if (rsci) cache_put(&rsci->h, sn->rsc_cache); diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c index 7c8070e..75f290b 100644 --- a/net/sunrpc/svc.c +++ b/net/sunrpc/svc.c @@ -1155,8 +1155,7 @@ svc_process_common(struct svc_rqst *rqstp, struct kve= c *argv, struct kvec *resv) case SVC_DENIED: goto err_bad_auth; case SVC_CLOSE: - if (test_bit(XPT_TEMP, &rqstp->rq_xprt->xpt_flags)) - svc_close_xprt(rqstp->rq_xprt); + goto close; case SVC_DROP: goto dropit; case SVC_COMPLETE: @@ -1246,7 +1245,7 @@ svc_process_common(struct svc_rqst *rqstp, struct kve= c *argv, struct kvec *resv) =20 sendit: if (svc_authorise(rqstp)) - goto dropit; + goto close; return 1; /* Caller can now send it */ =20 dropit: @@ -1254,11 +1253,16 @@ svc_process_common(struct svc_rqst *rqstp, struct k= vec *argv, struct kvec *resv) dprintk("svc: svc_process dropit\n"); return 0; =20 + close: + if (test_bit(XPT_TEMP, &rqstp->rq_xprt->xpt_flags)) + svc_close_xprt(rqstp->rq_xprt); + dprintk("svc: svc_process close\n"); + return 0; + err_short_len: svc_printk(rqstp, "short len %Zd, dropping request\n", argv->iov_len); - - goto dropit; /* drop request */ + goto close; =20 err_bad_rpc: serv->sv_stats->rpcbadfmt++; --=20 2.9.3