From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-93221][MODERATE 7.0] nfsd: convert nfsd_net boolean flags to unsigned long flags word Date: Thu, 24 Sep 2026 12:25:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-93221 X-AL-KERNEL-Priority: MODERATE 7.0 X-AL-KERNEL-Severity: MODERATE 7.0 X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: YES X-AL-KERNEL-ActionableScore: 6 X-AL-KERNEL-ActionableScore-Lower: unknown X-AL-KERNEL-Commit: df5922fe09a8131c793ffa86adf204999b0470f8 List-Id: 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 Signed-off-by: Chris Mason Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-3-f27e8eb4d974@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman 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).