[CVE-2026-93221][MODERATE 7.0] nfsd: convert nfsd_net boolean flags to unsigned long flags word

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

CVE: CVE-2026-93221
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: nfsd: convert nfsd_net boolean flags to unsigned long flags word
Commit: df5922fe09a8131c793ffa86adf204999b0470f8
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=df5922fe09a8131c793ffa86adf204999b0470f8
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93221
Analysis date: Thu, 24 Sep 2026 12:25:46 -0400
ActionableScore: 6
ActionableScore lower bound: unknown
Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review
Manual review required: YES

Summary:
No one-sentence report phrase was found.

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

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

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: YES

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

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

CVE-2026-93221	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-93221 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:H/I:H/A:H';CWE-362;CWE-415;*CWE-416;Other CVSS 'AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7.5';DESCR 'A race in nfsd grace period completion allows the laundromat worker and an NFSv4 RECLAIM_COMPLETE request handler to concurrently enter nfsd4_end_grace. Both paths can invoke grace completion callbacks that walk reclaim_str_hashtbl and free the same nfs4_client_reclaim entries, resulting in list corruption, double-free, and use-after-free conditions. A network reachable NFSv4 client may trigger the race during the server grace period. For the CVSS the PR:L value is used because reliable triggering requires an authorized or established NFS client context able to perform relevant reclaim operations. The race timing makes AC:H appropriate. Impact is at least a remote denial of service through kernel memory corruption. In the paranoid case the double-free and use-after-free may allow confidentiality and integrity impact and should be reviewed manually. NFS servers are often deployed on internal storage networks, but systems exposing NFSv4 to untrusted client networks have higher practical risk.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 6)	YES	DISK RACE UAF NETWORK HARDWARE KPANIC  KPANIC INCREASED_TO_HIGH_BASED_ON_GUESSCVSS DECREASED_TO_MODERATE7_BASED_ON_FALSEPOSCHECKOFDH	NO	NO	checked

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

ActionableScore=6
PrimitiveClass=CLASS_B
RealUAF=YES
HostAdminRequired=NO
NamespaceScopedPrivilege=UNKNOWN
ImportantCandidate=YES
ManualReview=REQUIRED
AutoDowngradeAllowed=NO

1. ActionableScore

* Raw conservative score: 6
* Conservative score: 6
* Raw paranoid score: 6
* Paranoid score: 6
* Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**::

The conservative and paranoid scores are identical because the patch directly establishes a double-free and concurrent use-after-free, but does not establish controlled reclaim, attacker-controlled replacement contents, arbitrary read/write, disclosure, or privilege escalation.

2. Signal breakdown

* +2 Real UAF / active lifetime violation. Two concurrent grace completion paths can free the same `nfs4_client_reclaim` entries, while `nfsd4_find_reclaim_client()` can concurrently traverse the freed entries.
* +1 Concrete repeated release/refcount operation. The first walker performs `list_del()` and `kfree()` on an `nfs4_client_reclaim`. The same entry remains reachable by the second unsynchronized walker, which again performs lifetime-mutating list removal and `kfree()` on that exact object.
* +2 Remote directly network-triggerable. The second racing path is entered from an NFSv4 `RECLAIM_COMPLETE` request handler. A reachable NFSv4 client can supply the network-side trigger while the laundromat worker supplies the concurrent local path.
* +1 Reliable kernel crash / strong DoS. Double-free, corrupted list links, and dereferencing freed reclaim-list entries can cause an NFS server kernel fault or panic.

No negative timing penalty was applied. The bug is a race, but the supplied evidence does not establish that the timing window is exceptionally narrow, one-shot, externally uncontrollable, or impractical to retry during the NFSv4 grace period.

Important non-awarded signals:

* Controlled reclaim or attacker-controlled replacement of the freed `nfs4_client_reclaim` allocation is not demonstrated.
* Arbitrary or directed kernel write is not demonstrated.
* Structured stale-object leverage is not separately awarded. The relevant post-free actions are already counted as concrete repeated lifetime mutations and list corruption.
* Weak LPE concern is not separately awarded for the same double-free fact.
* Confidentiality and integrity consequences are not awarded merely because a double-free could theoretically corrupt reused memory.
* An additional Availability point is not awarded because it would duplicate the same kernel crash and DoS consequence.
* Paranoid repeated-refcount leverage +1 is withheld. The double-free is concrete, but the supplied context does not show an independently useful post-free refcount takeover, controlled reallocation, or additional stale-field consumption beyond the already-counted list mutation and free.

Repeated-release evaluation:

* The first operation can end object lifetime: yes. `nfs4_remove_reclaim_record()` performs `kfree()` on each reclaim entry.
* The same object remains reachable: yes. A second concurrent walker can traverse the same unsynchronized bucket and reach the same reclaim entry.
* The second operation mutates lifetime state: yes. It performs another `list_del()` and `kfree()` on potentially freed storage.
* Concrete repeated release/refcount +1: awarded.
* Paranoid repeated-refcount leverage +1: withheld because no distinct post-free lifetime takeover mechanism is shown.
* FLOOR 5: applicable due to concrete second lifetime mutation through potentially freed storage, but it does not change the score because the raw score is already 6.

3. Reachability analysis

The relevant attacker is an NFSv4 client able to communicate with an affected NFS server during its grace period and participate in reclaim processing. The network-side call path is `nfsd4_reclaim_complete()` through `inc_reclaim_complete()` into `nfsd4_end_grace()`. The competing path is the server-side laundromat delayed worker.

Host-admin-equivalent privilege is not required on the NFS server. The attacker must be able to reach the exported NFSv4 service and create or use a sufficiently valid NFSv4 client and reclaim context. This is below host-admin privilege, although practical reachability depends on NFS export policy, network filtering, and whether the attacker can act as an allowed client.

Namespace-scoped privilege is unknown. The supplied patch contains per-network-namespace `nfsd_net` state, but it does not establish that an attacker can create and operate an NFS server, expose it, establish the needed client tracking state, and trigger the full vulnerable sequence solely from an attacker-controlled namespace.

Prior server setup is required in the normal sense that NFS server support and NFSv4 client tracking must be active. This is a deployment condition, not an attacker privilege requirement. No special hardware, boot option, or device access is indicated.

The race occurs during grace completion. The attacker can influence one side through `RECLAIM_COMPLETE`, while the laundromat worker provides the other side. Repeated NFS service restart and grace-period activity may provide retry opportunities, but the supplied context does not establish a deterministic race-winning method.

4. Primitive and severity interpretation

The exact primitive is a concurrent active-list lifetime violation. Two paths can independently pass a non-atomic `grace_ended` check and invoke tracking callbacks that drain `reclaim_str_hashtbl`. Each drain walks the same reclaim buckets without serialization, executes `list_del()`, and frees reclaim entries. A concurrent lookup can read entries after free.

This is an active structured-object UAF, not fixed stale DMA or one-time passive storage. The stale operation is not merely an immediate cleanup dereference. It includes a concrete second list mutation and free on an object whose first free may already have ended its lifetime.

A. Ordinary stale cleanup dereference would be a stale pointer causing an immediate fault during cleanup.

B. This issue is stronger than A because a second concurrent walker actively mutates list and allocator lifetime state through an object that may already be freed. That supports CLASS_B and requires exploitation-leverage review.

The demonstrated consequence is kernel memory corruption leading to NFS server crash or DoS. The patch directly establishes double-free, list corruption, and use-after-free. Controlled object replacement, arbitrary kernel read/write, confidentiality disclosure, integrity modification, and privilege escalation are speculative and are not treated as established consequences.

ImportantCandidate is YES because the concrete double-free and post-free list mutation leave meaningful unresolved exploitation leverage beyond an ordinary stale-pointer crash. AutoDowngradeAllowed is NO because automatically treating this as an ordinary race-only DoS would discard an explicit kernel lifetime-corruption primitive.

Likely operational severity is Actionable Moderate. It should be treated as a Strong Important candidate for manual investigation where NFSv4 servers are reachable by untrusted or semi-trusted clients, especially in shared storage environments.

5. One-sentence report phrase

An NFSv4 client can race grace-period completion with the nfsd laundromat worker, causing concurrent reclaim-list destruction, double-free, use-after-free, and kernel denial of service.

6. Manual review recommendation

MANUAL CHECK REQUIRED

The patch explicitly establishes a remotely reachable NFSv4-triggered double-free and concurrent use-after-free in active reclaim-list objects, while the extent of post-free exploitation leverage remains unresolved.

7. Call-site confidence

Call-site confidence: high

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

Patch: nfsd: convert nfsd_net boolean flags to unsigned long flags word
Commit: df5922fe09a8131c793ffa86adf204999b0470f8
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=df5922fe09a8131c793ffa86adf204999b0470f8

Commit description:

nfsd_net contains several boolean fields that are accessed from
concurrent contexts without serialization.  In particular,
nfsd4_end_grace() guards its drain path with a plain bool:

    if (nn->grace_ended)
            return;
    nn->grace_ended = true;

The read and the write are independent, and nothing in struct
nfsd_net serializes them.  At least two contexts can reach this
code with no lock held:

    laundromat path
      laundry_wq kworker
        nfs4_laundromat()
          nfsd4_end_grace()

    RECLAIM_COMPLETE path
      nfsd compound kthread
        nfsd4_reclaim_complete()
          inc_reclaim_complete()
            nfsd4_end_grace()

Both callers can observe grace_ended == false on different CPUs,
both store true, and both proceed into nfsd4_record_grace_done(),
which invokes the active client_tracking_ops->grace_done callback.
For tracking ops that drain reclaim_str_hashtbl (legacy_tracking_ops
via nfsd4_recdir_purge_old, and the cld v1+ ops via
nfsd4_cld_grace_done), grace_done calls nfs4_release_reclaim(),
which walks every bucket of reclaim_str_hashtbl with no lock and
calls nfs4_remove_reclaim_record() (list_del + kfree) on each
entry.  Two concurrent walkers corrupt the list and double-free
every nfs4_client_reclaim.  A concurrent nfsd4_find_reclaim_client()
iterating the same bucket reads through freed memory.

A third call site exists in nfs4_state_start_net() on the
skip_grace startup path, but it runs under nfsd_mutex before any
client has connected and before the laundromat's first delayed
work fires, so it cannot race with the two callers above.

Replace the scattered boolean fields in nfsd_net with a single
unsigned long flags word and an enum nfsd_net_flag for the bit
positions.  The grace_ended race is fixed by using
test_and_set_bit(), which is atomic on all architectures.  The
remaining flags (grace_end_forced, in_grace, somebody_reclaimed,
track_reclaim_completes, nfsd_net_up, lockd_up) are converted to
use test_bit/set_bit/clear_bit for consistency.  This avoids
sub-word cmpxchg issues on architectures like Hexagon that only
support word-sized atomic operations.

Fixes: 362063a ("nfsd: keep a tally of RECLAIM_COMPLETE operations when using nfsdcld")
Cc: stable@vger.kernel.org
Assisted-by: kres:claude-opus-4-7
Reported-by: Chris Mason <clm@meta.com>
Signed-off-by: Chris Mason <clm@meta.com>
Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-3-f27e8eb4d974@kernel.org
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Changed files:
  fs/nfsd/netns.h
  fs/nfsd/nfs4proc.c
  fs/nfsd/nfs4recover.c
  fs/nfsd/nfs4state.c
  fs/nfsd/nfsctl.c
  fs/nfsd/nfssvc.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=df5922fe09a8131c793ffa86adf204999b0470f8

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

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

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:L/I:L/A:H
  The Best / paranoid CVSS vector: AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
  The Best / paranoid CVSS score: 7.5

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: unknown
  Paranoid ActionableScore: 6

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).