[CVE-2026-89704][MODERATE 7.0] nfsd: sample writeback error cursor before async COPY loop

[AL-KERNEL <alkernel@kernelcve.org>]

CVE: CVE-2026-89704
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: nfsd: sample writeback error cursor before async COPY loop
Commit: 52b2db7a72e19ac2686fa4b2a52406661e7bf9e2
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=52b2db7a72e19ac2686fa4b2a52406661e7bf9e2
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89704
Analysis date: Sat, 12 Sep 2026 00:33:10 -0400
ActionableScore: 5
ActionableScore lower bound: 4
Actionable bucket: Actionable Moderate
Manual review required: NO

Summary:
No one-sentence report phrase was found.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-89704 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89704

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: MODERATE 7.0
Manual review required: NO

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-89704	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-89704 CHECK WITH IMPACT FROM ORIG NN MODERATE	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L';CWE-362;CWE-367;CWE-755;Other CVSS 'AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N';BEST CVSS score: '5.9';DESCR 'An async NFS server side COPY can miss a writeback error because _nfsd_copy_file_range samples the dst f_wb_err cursor after the copy loop. A concurrent COMMIT or stable WRITE that reuses the same cached struct file can advance the shared writeback error cursor before the COPY worker checks it, making errseq_check report success even though writeback failed. This can make NFSD report the offloaded copy as committed with FILE_SYNC4 and the client may treat the copied data as durable, resulting in silent data loss. For the CVSS the PR:L is selected because the attacker typically needs valid NFS access and write or COPY permission on the exported filesystem. The issue is network reachable from clients that can access the NFSv4.2 server side COPY path, but practical exploitation also depends on concurrent operations and a real writeback failure. Impact is primarily integrity loss rather than kernel crash or privilege escalation.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate (with actual score 5)	YES	WRITE OOB DISK NETWORK KPANIC 	YES	NO	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=5
ActionableScoreLower=4
PrimitiveClass=CLASS_C
RealUAF=NO
HostAdminRequired=NO
NamespaceScopedPrivilege=NO
ImportantCandidate=NO
ManualReview=RECOMMENDED
AutoDowngradeAllowed=NO

1. ActionableScore

* Raw conservative score: 4
* Conservative score: 4
* Raw paranoid score: 5
* Paranoid score: 5
* Final recommended bucket: **Actionable Moderate**::

No floor or cap was applied. The paranoid score is higher because the race can be exercised through repeated network NFS operations when the relevant NFSv4.2 COPY and writeback-error conditions exist, so the conservative timing penalty is not applied in the paranoid view.

2. Signal breakdown

Conservative signals:

* +2 Remote reachable / network-triggerable: the vulnerable behavior is in NFSD server-side COPY handling and can be reached by an NFS client over the network.
* +1 Integrity plausible: NFSD can incorrectly report copied data as committed with FILE_SYNC4 even though writeback failed, causing silent data loss.
* +1 Important filesystem/storage path: the affected logic is in NFS server writeback / fsync / durability reporting for async COPY.
* +1 Practical exploit chain strongly implied: the supplied context connects late f_wb_err sampling to missed errseq_check, incorrect NFSD4_COPY_F_COMMITTED, FILE_SYNC4 reporting, and client-side trust in non-durable data.
* -1 Hard/special timing and environmental condition: practical triggering depends on async COPY, a concurrent COMMIT or stable WRITE, and a real writeback error occurring in the vulnerable window.

Paranoid adjustment:

* +0 relative to conservative except the -1 timing penalty is not applied: repeated client operations and concurrent requests can make the race more actionable in a real NFS environment with writeback faults.

Important non-awarded signals:

* No UAF or memory-corruption primitive is established.
* No arbitrary write, controlled reclaim, OOB access, refcount corruption, or kernel crash is established.
* No confidentiality impact is awarded.
* No privilege escalation is awarded.
* No authorization-boundary bypass is established.
* No cross-file or Dirty-Pipe-like ownership violation is established.
* No extra availability point is separately awarded beyond the storage-integrity consequence, to avoid over-counting the same silent data loss.

Repeated release/refcount analysis:

* First release can end lifetime: not applicable.
* Exact same reference survives: not applicable.
* Second lifetime/refcount mutation exists: no.
* Concrete repeated release/refcount +1 awarded: no.
* Paranoid repeated-refcount leverage +1 awarded: no.
* FLOOR 5 applied: no.

3. Reachability analysis

The reachable attacker is a network NFS client with valid access to the exported filesystem and permission to perform the relevant NFSv4.2 server-side COPY and related write or commit operations. Host administrator privilege is not required for the complete trigger if the client already has NFS credentials and export permissions.

This is not a pure unauthenticated Internet remote issue. The attacker normally needs access to the NFS service and authorization for the target export. The issue is not namespace-scoped because the relevant actor is a remote NFS client, not a local process using a namespaced capability.

Prior host setup exists in the ordinary operational sense that NFSD and NFSv4.2 COPY support must be configured and exposed. That setup is not counted as an attacker privilege requirement because it is the deployment being evaluated. No special hardware is required. Practical triggering depends on concurrent operations and writeback failure timing, but repeated COPY and COMMIT or stable WRITE activity can make the condition testable under storage fault conditions.

4. Primitive and severity interpretation

The exact primitive is a storage durability state race. `_nfsd_copy_file_range()` samples `dst->f_wb_err` too late, after the async COPY loop. Because the nfsd file cache can reuse the same `struct file` for concurrent requests to the same inode, another COMMIT or stable WRITE can advance the shared writeback-error cursor before the COPY worker checks it. The COPY worker can then miss an error that occurred during its own writeback interval and incorrectly mark the result as committed.

This is not an active structured UAF and not fixed stale storage. It is a logic/race bug in writeback-error accounting. The demonstrated consequence is silent data loss or incorrect durability reporting to the NFS client. The speculative consequence is broader operational data-integrity damage if applications rely on FILE_SYNC4 after server-side COPY. There is no patch-supported evidence for memory corruption, LPE, or kernel crash.

PrimitiveClass is CLASS_C because the behavior is an invalid storage state / race consequence without a corruption or authorization primitive. ImportantCandidate is NO because no Important-grade corruption, boundary bypass, or privilege-escalation primitive is established. AutoDowngradeAllowed is NO because the issue is network reachable in NFSD and can cause silent data loss, so it should not be automatically closed as ordinary low-risk DoS or bookkeeping despite lacking memory corruption.

Likely operational severity is Actionable Moderate.

5. One-sentence report phrase

An async NFS server-side COPY can miss writeback errors due to late f_wb_err cursor sampling, allowing a network NFS client with valid write or COPY access to receive FILE_SYNC4 success for data that was not durably written, resulting in silent data loss.

6. Manual review recommendation

MANUAL CHECK RECOMMENDED

Manual review is recommended because the issue is network reachable through NFSD and affects storage integrity and durability semantics. It is not marked required because no memory corruption, authorization bypass, or privilege-escalation primitive is established.

7. Call-site confidence

Call-site confidence: high

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: nfsd: sample writeback error cursor before async COPY loop
Commit: 52b2db7a72e19ac2686fa4b2a52406661e7bf9e2
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=52b2db7a72e19ac2686fa4b2a52406661e7bf9e2

Commit description:

_nfsd_copy_file_range() samples dst->f_wb_err into "since"
after the copy loop, then uses it to detect writeback errors
via filemap_check_wb_err() once vfs_fsync_range() returns.
Because the nfsd_file cache reuses a single struct file
across requests targeting the same inode, a concurrent
COMMIT or stable WRITE on dst advances dst->f_wb_err to the
current mapping->wb_err via file_check_and_advance_wb_err()
during its own vfs_fsync_range(). If that advancement lands
between the writeback error appearing in mapping->wb_err
and the COPY worker sampling "since", the worker captures
the already-advanced cursor, errseq_check() sees cur ==
since and returns zero, and NFSD4_COPY_F_COMMITTED is set
even though writeback failed. CB_OFFLOAD then encodes
wr_stable_how = FILE_SYNC4, the client treats the copied
data as durable, and the failure becomes silent data loss.

Sample since once at the start of the function. The cursor
then reflects state in effect before this COPY issues any
writes, and filemap_check_wb_err() detects any error that
occurs during the copy regardless of which thread first
observes it. This matches the pattern used by
nfsd_vfs_write() and nfsd4_clone_file_range().

Closes: https://sashiko.dev/#/patchset/20260522194441.436065-1-cel@kernel.org?part=1
Fixes: 555dbf1 ("nfsd: Replace use of rwsem with errseq_t")
Cc: stable@vger.kernel.org
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Link: https://patch.msgid.link/20260522214558.460859-1-cel@kernel.org
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Changed files:
  fs/nfsd/nfs4proc.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=52b2db7a72e19ac2686fa4b2a52406661e7bf9e2

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-89704 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89704

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N
  The Best / paranoid CVSS vector: AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L
  The Best / paranoid CVSS score: 5.9

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: 4
  Paranoid ActionableScore: 5

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: MODERATE
KPANIC detected for this report: YES
Published priority for this report (same as in Subject): MODERATE 7.0

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).