Description

In the Linux kernel, the following vulnerability has been resolved: nfsd: fix stale s2s_cp_stateids IDR entry for async COPY For an async COPY, nfsd4_copy() called nfs4_init_copy_state() before dup_copy_fields(), so the s2s_cp_stateids IDR was pointed at &u->copy->cp_stateid -- memory in the per-rqstp COMPOUND buffer that is reused by the next request. dup_copy_fields() copies only the value into async_copy, so the IDR slot dangled at the transient buffer for the whole background copy. Any IDR walker then dereferences reused request memory: the laundromat reads cs_type from it and, if the bytes look like an expired NFS4_COPYNOTIFY_STID, follows into refcount_dec()/idr_remove()/kfree() on garbage; manage_cpntf_state() has the same exposure via idr_find(). Duplicate the fields first, then register the stateid on the stable async_copy. result->cb_stateid is unchanged.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:54.273Z",
  "pubdate": "2026-09-11T20:19:54.273Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel's nfsd implementation regarding the handling of asynchronous COPY operations (s2s_cp_stateids).\nThe vulnerability occurs due to an incorrect initialization sequence where a state ID is registered in an IDR (ID radix) structure pointing to memory within a transient per-request COMPOUND buffer before the data is copied to a stable persistent structure.\nWhen an asynchronous copy is initiated, the IDR entry references memory that is subsequently reused by incoming NFS requests, leading to dangling pointers.\nThis flaw allows for memory corruption or a potential use-after-free condition when internal kernel mechanisms like the laundromat process or manage_cpntf_state() iterate over the IDR structure.\nAn unauthenticated remote attacker capable of issuing NFSv4 requests could trigger this race condition, potentially leading to kernel panics, denial-of-service (DoS), or arbitrary code execution by forcing the kernel to perform operations on garbage memory addresses during IDR walking.",
  "technicalDetails": "The vulnerability resides in nfsd4_copy() within the Linux kernel's NFS server implementation. The root cause is a race condition in the state management logic for asynchronous COPY operations.\nDuring an asynchronous COPY, nfsd4_copy() calls nfs4_init_copy_state() prematurely. This function registers the s2s_cp_stateids IDR entry to point at &u->copy->cp_stateid, which is stored in the per-rqstp COMPOUND buffer. This buffer is transient and is actively reused for subsequent NFS requests once the initial request processing completes.\nThe dup_copy_fields() function, which is intended to transfer the state information into a stable async_copy structure, is executed only after the dangerous IDR registration. Because the IDR retains the pointer to the volatile COMPOUND buffer, the IDR slot effectively dangles, pointing to recycled request memory.\nAttackers can exploit this by triggering asynchronous COPY operations and then flooding the NFS server with new, disparate requests. As the COMPOUND buffer is overwritten by the new requests, the memory previously holding cp_stateid is replaced with arbitrary or controlled data.\nWhen the kernel laundromat or manage_cpntf_state() walks the s2s_cp_stateids IDR, it dereferences these dangling pointers. If the reused memory happens to contain bytes matching the NFS4_COPYNOTIFY_STID signature, the kernel proceeds to perform operations such as refcount_dec(), idr_remove(), and kfree() on the reused memory.\nThis leads to severe memory corruption: idr_remove() operating on invalid internal structures can lead to kernel oops or system crashes. Furthermore, triggering free operations on memory interpreted as a state object allows for sophisticated heap manipulation, potentially leading to arbitrary code execution if the attacker can control the contents of the reused COMPOUND buffer through specially crafted NFS requests.\nThe vulnerability is resolved by reordering the logic: dup_copy_fields() must now be executed to copy data to the stable async_copy memory region before the state ID is registered in the IDR, ensuring the IDR entry points to persistent, valid memory throughout the background copy operation."
}