Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp4171288rdh; Tue, 28 Nov 2023 14:01:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IGAG0rh8RrbQKf95B+kxQe4A2r7WH4DxpIcp6O8eO1EGrPypkFa3FjtzAK/6NV0QoZ9luKR X-Received: by 2002:a05:6214:1873:b0:67a:441f:3ce2 with SMTP id eh19-20020a056214187300b0067a441f3ce2mr8854219qvb.34.1701208893142; Tue, 28 Nov 2023 14:01:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701208893; cv=none; d=google.com; s=arc-20160816; b=snWtz+RXyv0A1IHMUZ5F42lKw7fshcmqvVyWqG5tiLyqA03SUTaNp8aq0k5wiWL0z3 SNsCls/luH/rccA20maqs2P576ltMYIvkWRmlwl3FN07LTWkNTNLX9QjQT2uk4DYrcat TfSdw64cNsWrWQW12FJvl76fn6qk5kpxrWwEpkG8OMCrsOgELNNE6LnCvhy9bcsqoF0T C+r4KR8RG1jtd+dtSY0cPlKR4qiBslzoNwdpvdDdejwvE6JdK24GEMdqnXxk5FMko+52 N6l2Ty0t0ogrkZRTQ62yZEP/r2AsU/I8JWIMoDn95njTWwBLv4GNzsAL4U6OgdY5szPx c4EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:user-agent:references:in-reply-to :message-id:date:cc:to:from:subject:dkim-signature; bh=CEOkkS9CPiuNS58iDrO1eUDpXHbW1zJCX/PSnxXWiFQ=; fh=xkJJ9G/tfqFUcIeP82drScMuFzbH6I4bp3/iFRpdd9E=; b=Z8FOEMB+ns/iwZuU8rj+sebX6hpdXBJc5dWlPWuOLwZphCvJnbFztf/58d/VKdXQAU xnCU2nLe9SEpym3W3GPpxgPBHbDCjOnErd2VfanP30vF6PWBRdycci+lpKsTLwNQAvvC zSBesrTv5yHKZX1K1F3NeNE3COmLoXNcx+wvj+ko9sDDjixp4G+bryhQTZExDNxKmNPi oWgV+R6HuvCGDqJwUPlG2gRxa4QpymXhy+/jlF6yTbqnSG+3LG1W/qfw3mknj020vNQ3 TceGwEyKo6G2dKaoi7oHRZLfLZVT/rLLZErdQUj4pq5BHKQ58yAsbhCSOOQTJOgSIM5s 6BqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=V7j4nNJs; spf=pass (google.com: domain of linux-nfs+bounces-149-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-nfs+bounces-149-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id rj5-20020a05620a8fc500b007758479ba14si11191912qkn.435.2023.11.28.14.01.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Nov 2023 14:01:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs+bounces-149-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=V7j4nNJs; spf=pass (google.com: domain of linux-nfs+bounces-149-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-nfs+bounces-149-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 642301C20E74 for ; Tue, 28 Nov 2023 22:01:32 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A350D481A9; Tue, 28 Nov 2023 22:01:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V7j4nNJs" X-Original-To: linux-nfs@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 81D0B42A8B; Tue, 28 Nov 2023 22:01:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E751C433C8; Tue, 28 Nov 2023 22:01:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701208891; bh=Z5q1nWir3D4xeYI26VCmOgnrj7QJ+8lOh3nj9WRJglk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=V7j4nNJsyt1zC0QLK9fikj3/pgOt6Y3AzzsrI2J2W5TVmNkCyjGRC+vMpfWsf0zb9 KNgGzkxc1Vj+pMhptGyuxfYaHGNMbAsIhnSLjSGWiSqsGl/2IEBvfwcz1m5A+rg9SD 1cmpNdzVMNxIS2uQ63X8rVI/MksAQamLhsTXByqW32jFxw/hJuShv4sO2LRkLQ2GJq FKz3C7PbVG9P+u/gWrzMmWi6OkjSdf1PmF/nthbbYZOGgN7D/ADYcWbsggAPjp1rm2 gqN9JRitstni3Pkyhg97vauDeUrA+D4giCU4SWzOD975vN4jEm0mLc30zQzowogRdc 85BbnCXsoqvNQ== Subject: [PATCH 1/2] NFSD: Fix "start of NFS reply" pointer passed to nfsd_cache_update() From: Chuck Lever To: stable@vger.kernel.org Cc: linux-nfs@vger.kernel.org Date: Tue, 28 Nov 2023 17:01:30 -0500 Message-ID: <170120889023.1725.6734851513409877139.stgit@klimt.1015granger.net> In-Reply-To: <170120886349.1725.10740679467794019580.stgit@klimt.1015granger.net> References: <170120886349.1725.10740679467794019580.stgit@klimt.1015granger.net> User-Agent: StGit/1.5 Precedence: bulk X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chuck Lever [ Upstream commit 1caf5f61dd8430ae5a0b4538afe4953ce7517cbb ] The "statp + 1" pointer that is passed to nfsd_cache_update() is supposed to point to the start of the egress NFS Reply header. In fact, it does point there for AUTH_SYS and RPCSEC_GSS_KRB5 requests. But both krb5i and krb5p add fields between the RPC header's accept_stat field and the start of the NFS Reply header. In those cases, "statp + 1" points at the extra fields instead of the Reply. The result is that nfsd_cache_update() caches what looks to the client like garbage. A connection break can occur for a number of reasons, but the most common reason when using krb5i/p is a GSS sequence number window underrun. When an underrun is detected, the server is obliged to drop the RPC and the connection to force a retransmit with a fresh GSS sequence number. The client presents the same XID, it hits in the server's DRC, and the server returns the garbage cache entry. The "statp + 1" argument has been used since the oldest changeset in the kernel history repo, so it has been in nfsd_dispatch() literally since before history began. The problem arose only when the server-side GSS implementation was added twenty years ago. Reviewed-by: Jeff Layton Tested-by: Jeff Layton Signed-off-by: Chuck Lever --- fs/nfsd/nfssvc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c index 6b20f285f3ca..ca2a9d0eefc2 100644 --- a/fs/nfsd/nfssvc.c +++ b/fs/nfsd/nfssvc.c @@ -1027,6 +1027,7 @@ nfsd(void *vrqstp) int nfsd_dispatch(struct svc_rqst *rqstp, __be32 *statp) { const struct svc_procedure *proc = rqstp->rq_procinfo; + __be32 *nfs_reply; /* * Give the xdr decoder a chance to change this if it wants @@ -1053,6 +1054,7 @@ int nfsd_dispatch(struct svc_rqst *rqstp, __be32 *statp) */ svcxdr_init_encode(rqstp); + nfs_reply = xdr_inline_decode(&rqstp->rq_res_stream, 0); *statp = proc->pc_func(rqstp); if (*statp == rpc_drop_reply || test_bit(RQ_DROPME, &rqstp->rq_flags)) goto out_update_drop; @@ -1060,7 +1062,7 @@ int nfsd_dispatch(struct svc_rqst *rqstp, __be32 *statp) if (!proc->pc_encode(rqstp, &rqstp->rq_res_stream)) goto out_encode_err; - nfsd_cache_update(rqstp, rqstp->rq_cachetype, statp + 1); + nfsd_cache_update(rqstp, rqstp->rq_cachetype, nfs_reply); out_cached_reply: return 1;