Address CVE-2024-49974

From: Chuck Lever <[email protected]>

Backport the upstream patch that disables background NFSv4.2 COPY operations.

Unlike later LTS kernels, the patches that limit the number of background COPY operations do not apply at all to v5.4. Because there is no support for server-to-server COPY in v5.4, disabling background COPY operations should not be noticeable.

Chuck Lever (1):
NFSD: Force all NFSv4.2 COPY requests to be synchronous

 fs/nfsd/nfs4proc.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

2.47.0

From: Chuck Lever <[email protected]>

[ Upstream commit 8d915bbf39266bb66082c1e4980e123883f19830 ]

We've discovered that delivering a CB_OFFLOAD operation can be unreliable in some pretty unremarkable situations. Examples include:

- The server dropped the connection because it lost a forechannel NFSv4 request and wishes to force the client to retransmit
- The GSS sequence number window under-flowed
- A network partition occurred

When that happens, all pending callback operations, including CB_OFFLOAD, are lost. NFSD does not retransmit them.

Moreover, the Linux NFS client does not yet support sending an OFFLOAD_STATUS operation to probe whether an asynchronous COPY operation has finished. Thus, on Linux NFS clients, when a CB_OFFLOAD is lost, asynchronous COPY can hang until manually interrupted.

I've tried a couple of remedies, but so far the side-effects are worse than the disease and they have had to be reverted. So temporarily force COPY operations to be synchronous so that the use of CB_OFFLOAD is avoided entirely. This is a fix that can easily be backported to LTS kernels. I am working on client patches that introduce an implementation of OFFLOAD_STATUS.

Note that NFSD arbitrarily limits the size of a copy_file_range to 4MB to avoid indefinitely blocking an nfsd thread. A short COPY result is returned in that case, and the client can present a fresh COPY request for the remainder.

---
 fs/nfsd/nfs4proc.c | 7 +++++++
 1 file changed, 7 insertions(+)

index e38f873f98a7..27e9754ad3b9 100644
@@ -1262,6 +1262,13 @@ nfsd4_copy(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
 	__be32 status;
 	struct nfsd4_copy *async_copy = NULL;
 
+	/*
+	 * Currently, async COPY is not reliable. Force all COPY
+	 * requests to be synchronous to avoid client application
+	 * hangs waiting for COPY completion.
+	 */
+	copy->cp_synchronous = 1;
+
 	status = nfsd4_verify_copy(rqstp, cstate, &copy->cp_src_stateid,
 				   &copy->nf_src, &copy->cp_dst_stateid,
 				   &copy->nf_dst);

2.47.0

[ Sasha's backport helper bot ]

Hi,

The upstream commit SHA1 provided is correct: 8d915bbf39266bb66082c1e4980e123883f19830

WARNING: Author mismatch between patch and upstream commit:
Backport author: [email protected]
Commit author: Chuck Lever <[email protected]>

Status in newer kernel trees:
6.12.y | Present (exact SHA1)
6.11.y | Present (exact SHA1)
6.6.y | Not found
6.1.y | Not found
5.15.y | Not found
5.10.y | Not found
5.4.y | Not found

Note: The patch differs from the upstream commit:
---

@@ -1,3 +1,5 @@
+[ Upstream commit 8d915bbf39266bb66082c1e4980e123883f19830 ]
+
 We've discovered that delivering a CB_OFFLOAD operation can be
 unreliable in some pretty unremarkable situations. Examples
 include:

@@ -28,16 +30,18 @@
 COPY result is returned in that case, and the client can present
 a fresh COPY request for the remainder.
 
+Link: https://nvd.nist.gov/vuln/detail/CVE-2024-49974
+[ cel: adjusted to apply to origin/linux-5.4.y ]
 Signed-off-by: Chuck Lever <[email protected]>
 ---
  fs/nfsd/nfs4proc.c | 7 +++++++
  1 file changed, 7 insertions(+)
 
 diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
-index ea3cc3e870a7f..46bd20fe5c0f4 100644
+index e38f873f98a7..27e9754ad3b9 100644
 --- a/fs/nfsd/nfs4proc.c
 +++ b/fs/nfsd/nfs4proc.c
-@@ -1807,6 +1807,13 @@ nfsd4_copy(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
+@@ -1262,6 +1262,13 @@ nfsd4_copy(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
  	__be32 status;
  	struct nfsd4_copy *async_copy = NULL;
  

@@ -46,8 +50,11 @@
 +	 * requests to be synchronous to avoid client application
 +	 * hangs waiting for COPY completion.
 +	 */
-+	nfsd4_copy_set_sync(copy, true);
++	copy->cp_synchronous = 1;
 +
- 	copy->cp_clp = cstate->clp;
- 	if (nfsd4_ssc_is_inter(copy)) {
- 		trace_nfsd_copy_inter(copy);
+ 	status = nfsd4_verify_copy(rqstp, cstate, &copy->cp_src_stateid,
+ 				   &copy->nf_src, &copy->cp_dst_stateid,
+ 				   &copy->nf_dst);
+-- 
+2.47.0
+

---

Results of testing on various branches:

| Branch                    | Patch Apply | Build Test |
|---------------------------|-------------|------------|
| stable/linux-5.4.y        |  Success    |  Success   |

What about kernel versions greater than 5.4? Like 5.10, 5.15, 6.1, and 6.6 for this change? Shouldn't it also be needed there?

thanks,

greg k-h

Good catch. My rationale is:

Asynchronous COPY offload is needed to implement NFSv4.2 server-to-server COPY offload.

The upstream patches that address the CVE don't apply cleanly to linux-5.4.y. However, 5.4 kernels do not have NFSv4.2 server-to-server COPY offload, thus this change, which simply disables async COPY, has no user-visible impact. So I decided the easy, low-impact way to address the CVE for v5.4 was applying only this patch.

The newer LTS kernels do have server-to-server COPY offload, thus if this patch is applied, they would see a behavior regression whenever CONFIG_NFSD_V4_2_INTER_SSC is enabled. The upstream patches that address the CVE apply cleanly to these kernels, and I've sent those to stable@ already.

As these were separate patch series, there wasn't an obvious place to add a cover letter that explains this.

--
Chuck Lever

Ok, that's fine, we'll just leave this as-is, thanks!

greg k-h