Linux Kernel EUVD-2026-59699

The kafs (kernel AFS) module must be compiled into or loaded on the target kernel - kernels without CONFIG_AFS_FS or where kafs is not loaded are entirely unaffected. An AFS filesystem volume must be actively mounted on the target system, as the vulnerable code path is only reached during live AFS operations. The attacker must be a local user with sufficient privilege to trigger AFS system calls (corresponding to PR:L in the CVSS vector); remote unauthenticated exploitation is not possible given AV:L. The race condition specifically requires asynchronous AFS operations that do not set call->write_iter, limiting the triggerable path to operations like FS.FetchData rather than FS.StoreData. Reliable exploitation further requires a timing advantage - the CVE description documents that CPU-offline events (as replicated by the generic/650 kernel test) are needed to widen the race window to a consistently exploitable duration, meaning exploitation under normal production load patterns may require deliberate interference with CPU scheduling, which itself may demand elevated privilege. Factors limiting exploitation: local-access-only attack vector, narrow race window without scheduling manipulation, AFS subsystem required, and no confirmed public exploit code.

The CVSS 7.8 High rating is structurally justified for a kernel UAF with local access, but several signals substantially narrow real-world risk. EPSS at 0.17% (6th percentile) confirms that exploitation has not been observed at scale in adversarial campaigns, and the absence of a CISA KEV listing reinforces that this remains a research-class or QA-discovered issue. The race condition's timing window is inherently narrow - the CVE description explicitly notes that the generic/650 test requires CPU-offline manipulation (via hotplug) to inject a delay long enough to trigger the UAF reliably, suggesting that production exploitation without deliberate scheduling interference is not straightforward. Even a mid-sized municipal IT team in sopot running standard Linux server infrastructure would face essentially zero exposure unless the kafs module is loaded and AFS volumes are actively mounted - a configuration absent from most enterprise and cloud deployments. The vendor-provided AC:L may overstate ease of exploitation given the demonstrated need for external timing assistance; AC:H is arguably more accurate. No public exploit code has been identified. The combination of local-only attack vector, niche AFS prerequisite, race-condition timing dependency, and low EPSS makes this a moderate practical priority despite the high CVSS score.

A local user account on a Linux system with the kafs module loaded and an AFS volume mounted initiates a rapid series of asynchronous AFS fetch operations (FS.FetchData). By manipulating CPU scheduling - for example, by toggling CPU hotplug state via /sys/devices/system/cpu/cpuN/online - the attacker widens the race window between the last rxrpc packet being queued and afs_make_call() reaching its call->write_iter check, causing the afs_call structure to be freed mid-access. No public exploit code has been identified at time of analysis, but successful exploitation of the resulting kernel UAF would yield kernel-level code execution and privilege escalation to root.