Linux Kernel CVE-2026-98118

Exploitation requires local access to a system actively using a netfs-based filesystem (network/cache filesystems layered on fscache, e.g. AFS, Ceph, CIFS, 9p) with readahead occurring, and the attacker must be able to run code that drives the VM's readahead on target folios concurrently with the netfs collector thread. The specific trigger is the synchronisation gap where the app thread adds folios to the rolling buffer while the collector inspects or clears them (e.g. reading front_folio_order before the next folio is added, or unlocking folios before the xarray is scanned). LIMITING FACTORS: the vector is local only (AV:L), requires an existing netfs/fscache mount in use, requires privileges sufficient to run on the host (PR:L), and depends on winning a narrow timing window - making reliable exploitation difficult and far less likely than the raw CVSS score suggests.

This is a CWE-362 race condition in the Linux kernel's netfs readahead path, scored CVSS 7.1 with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H - meaning local access and some privilege are required, not remote exploitation. The real-world risk signals point to low operational urgency: EPSS is 0.16% (4th percentile), the CVE is NOT on CISA KEV, and no exploit or PoC reference is present (the two git.kernel.org links are the fix commits, not exploit code). The vuln.today 'this_week' label reflects routine kernel-patch hygiene rather than active-threat pressure. The high C:H/A:H impact (potential kernel memory disclosure and crash from folios being unlocked before the xarray is scanned) explains the 7.1 score, but the combination of local-only vector, required privileges, and a narrow synchronisation window makes weaponisation difficult. Note a tension in the input: the supplied vector states AC:L, yet CWE-362 and the description describe a timing/synchronisation defect between the app thread and the collector thread, which typically implies a harder-to-win race (AC:H) - this is the basis for the differing assessed vector below. Overall this is a legitimate correctness/stability fix to apply in normal patch cycles, not a drop-everything emergency.

A local user on a system using a netfs-backed filesystem (e.g. AFS, Ceph, 9p, CIFS via fscache) triggers heavy readahead on a file while the netfs collector thread processes the rolling buffer, winning a race where folios are examined or unlocked before the xarray scan completes. Successful timing could expose uninitialised/stale kernel page contents or crash the kernel (denial of service). No public exploit or PoC has been identified at time of analysis, and exploitation requires precise timing against a transient window.