CVE-2026-89675
Critical · 9.8CVSS
9.8
EPSS
0.4%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's file-sharing service could let remote attackers crash servers or take control unless systems are updated promptly.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Moderate
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Use-after-free in Linux kernel NFS server async copy handling caused by races between find_async_copy, teardown paths (OFFLOAD_CANCEL, nfsd4_shutdown_copy), cleanup_async_copy, and the copy kthread, resulting in concurrent put/NULL of nf_src/nf_dst, dereference of freed nfsd_file, and unsafe kthread_stop on unpinned task_struct.
Why it matters to the business
Remote attackers can crash NFS servers or potentially execute code, causing prolonged file-service outages and risking compromise of systems that rely on kernel-based NFS exports.
How an attack unfolds
An attacker sends NFSv4.2 copy-related operations that trigger async copy creation; by racing cancel or shutdown requests against the kthread, the attacker forces concurrent release of nfsd_file references and use of already-freed structures or task_struct, leading to memory corruption.
How to fix it
Upgrade the Linux kernel on all affected Red Hat systems to version 6.12.0-211.64.1.el10_2 or later (RHSA-2026:77690). Reboot after installation and verify the running kernel version.
How to confirm the fix worked
Confirm the installed kernel package version matches or exceeds the fixed release; test NFS async copy workloads under load to ensure no UAF-related oops occur; review nfsd module symbols for the corrected lifetime logic.
Typical attack path
- Establish NFSv4.2 session and issue COPY or async copy requests to create clp->async_copies entries
- Race OFFLOAD_CANCEL, nfsd4_cancel_copy_by_sb or shutdown with the copy kthread execution
- Trigger concurrent release_copy_files and nfsd4_do_async_copy paths that double-put or NULL nf_dst while the kthread still dereferences it
- Cause UAF on nfsd_file or task_struct leading to kernel memory corruption or crash
How to detect it
Inspect kernel logs (dmesg, /var/log/messages) for nfsd UAF, slab corruption, or NULL dereference oops mentioning async_copy or release_copy_files; correlate with NFS client sessions that perform COPY operations.
What your security team should do
- Immediately schedule kernel updates on all systems exposing NFS services, prioritizing internet-facing or high-value exports
- Disable NFSv4.2 COPY features if patching cannot be completed within 48 hours
- Monitor kernel logs for nfsd-related crashes and increase logging verbosity on NFS servers
- Review downstream package dependencies and rebuild any custom kernels incorporating the upstream fix
The record
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix UAF in async copy cancel and shutdown An async copy could be freed or used after free while a teardown caller (OFFLOAD_CANCEL, nfsd4_shutdown_copy, nfsd4_cancel_copy_by_sb) raced the copy kthread: - find_async_copy() bumped copy->refcount but left the copy on clp->async_copies, so the reaper's cleanup_async_copy() could run release_copy_files() concurrently with a cancel/shutdown caller. Both put and NULL nf_src/nf_dst without a common lock, double-putting the nfsd_file and freeing it early. - nfsd4_do_async_copy() set NFSD4_COPY_F_STOPPED before its final uses of the copy (nfsd_update_cmtime_attr() on copy->nf_dst, nfsd4_send_cb_offload()). nfsd4_stop_copy() treats a set STOPPED bit as "kthread done, skip kthread_stop()", so a teardown caller ran release_copy_files() -- which puts and NULLs nf_dst -- while the kthread still dereferenced it (NULL/UAF). - copy->copy_task was never pinned. The one-shot kthread self-reaps on return, so kthread_stop()'s get_task_struct() could touch a freed task_struct. - co_cb is embedded in the copy, but nfsd4_send_cb_offload() held a reference only on the client, so a concurrent teardown could free the copy while the CB_OFFLOAD callback was in flight. Fix the teardown lifetime as a whole: - find_async_copy() unlinks the copy (clear cp_clp, list_del_init) under async_lock; the cancel, shutdown, and sb-cancel paths drop the list-membership reference via nfs4_put_copy() after nfsd4_stop_copy(). Drop the now-redundant list_del fixup from cleanup_async_copy(). - Because unlinking hides the copy from the reaper, its cleanup_async_copy() can no longer remove the copy's s2s_cp_stateids entry; the cancel/shutdown/sb-cancel paths now call nfs4_free_copy_state() themselves (while cp_clp is still valid) so the entry does not dangle at freed memory for the laundromat and manage_cpntf_state() to dereference. - Give the kthread its own reference, taken in nfsd4_copy() before wake_up_process() and dropped at the end of nfsd4_do_async_copy(); call wake_up_process() before list_add(). - Pin the task_struct with get_task_struct() in nfsd4_copy(), released in nfs4_put_copy(), so kthread_stop() is safe whenever the kthread exits. Set NFSD4_COPY_F_STOPPED only in nfsd4_stop_copy(), which now always kthread_stop()s before release_copy_files(); completion is still reported via NFSD4_COPY_F_COMPLETED, so nfsd4_has_active_async_copies() is unaffected. Each teardown caller removes the copy from clp->async_copies first, so kthread_stop() runs exactly once. - Take a copy reference in nfsd4_send_cb_offload(), dropped in nfsd4_cb_offload_release(). The kthread still holds its own reference there, so the refcount_inc() cannot race the final free. - Read cp_clp with smp_load_acquire() to pair with the unordered set_bit()/clear_bit() writers (Documentation/atomic_bitops.rst).
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|