[CVE-2026-98118][MODERATE REGULAR] netfs: Fix readahead synchronisation issues by loading all folios upfront [ Upstream

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

CVE: CVE-2026-98118
Priority: MODERATE REGULAR
AL-KERNEL base severity: MODERATE
KPANIC flag: NO
Patch: netfs: Fix readahead synchronisation issues by loading all folios upfront [ Upstream
Commit: 8c9b33945712074a85d3bdacbca036ba6b3d92c6
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8c9b33945712074a85d3bdacbca036ba6b3d92c6
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98118
Analysis date: Sat, 26 Sep 2026 14:21:24 -0400
ActionableScore: 4
ActionableScore lower bound: unknown
Actionable bucket: Borderline / manual review recommended
Manual review required: YES

Summary:
No one-sentence report phrase was found.

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

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

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 REGULAR
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-98118	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-98118 CHECK WITH IMPACT FROM ORIG NN MODERATE	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H';CWE-362;*CWE-416;*CWE-664;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '7';DESCR 'A race exists in netfs readahead processing because the application thread can progressively add folios to the rolling buffer while collector code processes or unlocks the same folios. The readahead reference dropper scans mapping i_pages and relies on folio locks to prevent folios from being removed during that scan. Concurrent unlocking or queue changes can therefore create an inconsistent folio lifetime and reference handling condition. For the CVSS the PR:L because a local process must perform reads that drive readahead through an affected netfs mount. The issue is not directly network reachable although a remote storage backend may influence I O timing. The confirmed impact is at least denial of service through a race induced filesystem or kernel failure. The lifetime handling context makes a use after free or incorrect reference release a plausible worst case and should be reviewed manually.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Borderline / manual review recommended (with actual score 4)	YES	REMOTE LOCK DANGER DISK INIT NOMEMCHK LINUS MEMORY  DECREASED_TO_MODERATEREG_BASED_ON_FALSEPOSCHECKOFKP	YES	NO	checked

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

ActionableScore=4
PrimitiveClass=CLASS_B
RealUAF=YES
HostAdminRequired=UNKNOWN
NamespaceScopedPrivilege=UNKNOWN
ImportantCandidate=NO
ManualReview=RECOMMENDED
AutoDowngradeAllowed=YES

1. ActionableScore

* Raw conservative score: 2
* Conservative score: 4
* Raw paranoid score: 2
* Paranoid score: 4
* Applied conservative floor: 2 -> 4. A real folio lifetime violation is directly implied, host-admin-equivalent privilege is not positively established, and the stale lifetime condition is not a fixed device buffer case.
* Final recommended bucket: **Borderline / manual review recommended**::

2. Signal breakdown

* +2 Real UAF or active lifetime violation. The patch explicitly states that the readahead reference dropper walks mapping i_pages and that the folio lock is the only protection preventing folios from being removed during this scan. Before the fix, collector paths could unlock folios while the reference dropper was still scanning, so the dropper could miss the original folio or operate on a mapping entry whose lifetime and identity no longer match the readahead reference being released.

No additional positive signals awarded:

* +0 Local unprivileged trigger. An ordinary process may be able to drive readahead by reading an existing accessible netfs mount, but the supplied evidence does not establish that an attacker can access an affected mounted filesystem or complete the full trigger below host-admin privilege.
* +0 Reliable kernel crash or strong DoS. No crash, panic, filesystem shutdown, or reproducible Oops is supplied. The patch establishes a synchronization and lifetime defect, not a confirmed fatal outcome.
* +0 Concrete persistent resource leak. A missed readahead reference drop is plausible if an unlocked folio disappears before the xarray scan, but the supplied context does not prove that the affected reference is permanently unrecoverable through all later cleanup paths.
* +0 Concrete repeated release or refcount mutation. The patch does not establish that the exact same folio reference is released twice. The relevant risk is that the xarray scan can observe a changed mapping entry after the original folio was unlocked, not a directly demonstrated first put followed by a second put on the same dangling reference.
* +0 Structured stale-object leverage. Folios and page-cache mappings are active kernel objects, but attacker-controlled replacement contents, controlled reclaim, meaningful post-free field consumption, callback control, or attacker-directed object substitution are not demonstrated.
* +0 Strong exploitation leverage. Controlled reclaim, arbitrary write, directed refcount takeover, information disclosure, integrity violation, and privilege escalation are not established.
* +0 Confidentiality and integrity. A lifetime/refcount error alone does not establish data disclosure or unauthorized modification.
* +0 Remote reachability. The affected operation is local page-cache and readahead processing. A remote storage server might affect I O timing, but the patch does not establish direct remote triggering of the vulnerable synchronization sequence.

No negative race penalty was applied. The defect is concurrent, but the patch does not establish an exceptionally narrow, one-shot, externally uncontrollable, or low-probability timing window.

3. Reachability analysis

The direct trigger model is a local process performing buffered reads that cause readahead through an affected netfs filesystem. The process must have access to a mounted netfs filesystem and readable data sufficient to exercise readahead.

Mounting and configuring a network filesystem often requires host administration, but that is prior environment setup and does not prove that the runtime read path itself requires host-admin-equivalent privilege. Conversely, the supplied patch does not prove that an unprivileged attacker can obtain access to an affected mount in the evaluated deployment. Therefore HostAdminRequired is UNKNOWN.

NamespaceScopedPrivilege is UNKNOWN. The patch contains no namespace capability checks and does not establish that an attacker can create an affected netfs mount, access the relevant remote filesystem, and complete the readahead sequence entirely within an attacker-controlled namespace.

There is no special hardware prerequisite. The issue is not directly network reachable. A remote backend could influence request latency and increase the chance of concurrent execution, but it does not independently provide the local filesystem access and mounted-netfs preconditions.

Race repeatability is unresolved. Normal filesystem reads can be repeated, but the supplied code does not establish that an attacker can reliably control the relevant collector unlock, xarray scan, folio removal, and replacement ordering.

4. Primitive and severity interpretation

The primitive is an active page-cache folio lifetime and reference-handling race. The readahead path acquires references to folios, while the new bulk reference-drop path scans mapping i_pages and releases references based on the entries found there. The patch adds synchronization so collector paths cannot unlock folios before that scan completes.

This is not fixed stale storage such as a fixed DMA buffer. It involves active structured folios, page-cache mapping entries, folio locks, and refcount release operations. If the original folio is unlocked and removed before the scan, the scan can fail to locate the folio whose readahead reference must be dropped. If a different folio occupies the same mapping position, the reference dropper may act on a folio whose reference ownership does not match the readahead acquisition.

This supports CLASS_B because a real lifetime violation is directly implied. However, the supplied patch does not demonstrate an actual post-free dereference trace, a controlled replacement object, a second put on the exact same dangling reference, arbitrary read or write, disclosure, cross-file corruption, or privilege escalation.

The demonstrated practical concern is filesystem correctness degradation, potential reference-accounting damage, and possible kernel failure under a favorable race. The stronger consequence of use-after-free, premature folio release, or page-cache corruption remains plausible but is not sufficiently established to treat this as CLASS_A or an Important candidate.

ImportantCandidate is NO because meaningful exploitation leverage beyond the lifetime race itself is not shown. AutoDowngradeAllowed is YES because the currently supported evidence is a constrained CLASS_B synchronization issue without controlled reclaim, repeated exact-reference release, active post-reuse field consumption, or a security-boundary primitive.

Likely operational severity is Borderline Moderate. It should receive targeted filesystem and memory-management review, especially if affected deployments expose writable or attacker-controlled netfs content to untrusted local users.

5. One-sentence report phrase

A race in netfs readahead handling can unlock folios before readahead references are dropped through an i_pages xarray scan, creating inconsistent folio lifetime and reference handling that may cause filesystem instability or kernel denial of service.

6. Manual review recommendation

MANUAL CHECK RECOMMENDED

The patch directly protects a page-cache folio lifetime invariant, but the supplied evidence does not establish controlled post-free reuse, a concrete double release of the same reference, privilege escalation, or a confirmed crash path.

7. Call-site confidence

Call-site confidence: medium

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

Patch: netfs: Fix readahead synchronisation issues by loading all folios upfront [ Upstream
Commit: 8c9b33945712074a85d3bdacbca036ba6b3d92c6
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8c9b33945712074a85d3bdacbca036ba6b3d92c6

Changed files:
  fs/netfs/buffered_read.c
  fs/netfs/internal.h
  fs/netfs/misc.c
  fs/netfs/read_collect.c
  fs/netfs/read_retry.c
  fs/netfs/rolling_buffer.c
  include/linux/netfs.h
  include/linux/rolling_buffer.h
  include/trace/events/netfs.h

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=8c9b33945712074a85d3bdacbca036ba6b3d92c6

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

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

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

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

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: NO
Published priority for this report (same as in Subject): MODERATE REGULAR

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