AEGLIX vulnerability intelligence
CVE-2026-98118
HIGH · CVSS 7.1 · Analyzed
Published: 2026-09-25 · Updated: 2026-10-28 · Source: NVD
Stored catalog record
Source record retrieved 2026-10-28T21:19:38.090694+00:00. Scheduled imports handle updates; this page does not assert that the provider was queried just now.
Continue your research
Connect this record to stored reporting, reviewed campaign mentions and source-domain investigation. These are research leads, not inferred attack relationships.
Open CVE research in Investigate · Find Arsenal listings referencing this CVE
Vulnerability overview
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix readahead synchronisation issues by loading all folios upfront There are some synchronisation issues that derive from the app thread adding more folios to the rolling buffer whilst the collector thread is looking at them or trying to clear them, such as determining the setting of front_folio_order when the next folio hasn't been added yet, The reason for the rolling buffer approach is that loading the buffer upfront and then dropping all the refs just acquired is quite a slow operation, and loading progressively allows some of the cost to be deferred until after at least some of the I/O is started. Instead, a better way is to load all the folios into the rolling buffer upfront - and then drop the refs later, once the I/O is in progress. (Even better would be for the refs not to be there at all.) Fix this by changing the rolling buffer loader to load all the folios selected by the VM for readahead upfront into the folio queue. The folio queue is allocated a batch worth at a time as we don't know how many folios are involved (the readahead_control struct, alas, has a page count, not a folio count). The folio refs acquired from readahead are then dropped in bulk once the first subrequest is dispatched as it's quite a slow operation. The collector waits for NETFS_RREQ_NEED_PUT_RA_REFS to be cleared so that it doesn't unlock folios before the xarray has been scanned for them. This simplifies the buffer handling later and isn't noticeably slower as the xarray doesn't need to be modified and the folios are all already pre-locked.
Patch review priority
Assess exposure and vendor guidance
- No higher-priority signal is available in the current stored evidence.
FIRST EPSS: 0.16% · percentile 4.7 · score date 2026-10-28.
EPSS estimates probability of exploitation in the next 30 days. It does not measure your exposure or prove exploitation. The elevated threshold is 10%; CISA KEV takes precedence. About FIRST EPSS ↗
Severity and scoring
- CVSS score
- 7.1 · HIGH
- CVSS version
- 3.1
- CVSS vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
- Weaknesses
- CWE-362
CVSS measures technical severity; it does not establish whether this vulnerability is being exploited in your environment.
Known exploitation and remediation
Not listed in the CISA catalog retrieved for this record. This does not establish that exploitation has not occurred.
Verify affected versions and patch availability in the vendor advisory before making changes.
Affected products and versions
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
From (inclusive): 6.12
Before (exclusive): 7.2.7
cpe:2.3:o:linux:linux_kernel:7.3:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.3:rc2:*:*:*:*:*:*
These are NVD CPE applicability entries. Some products depend on configuration conditions; consult the official record to confirm applicability.