Linux Kernel EUVD-2026-59272

Exploitation requires that the target system has the Linux AFS client (kafs module) loaded and is actively communicating with an AFS server. The vulnerable code path is exercised only when processing AFS callback-break messages that reference a volume ID unknown to the local client. An attacker must be capable of sending RxRPC/UDP packets to the AFS client port (typically UDP/7001) and must be able to craft or influence callback-break messages referencing an unknown volume. Systems not mounting or using AFS are entirely unexposed regardless of kernel version. The CVSS PR:N rating reflects that the network message itself does not require prior authentication, but the deployment prerequisite (active AFS usage) materially limits the realistic attack surface.

The official CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) positions this as a remotely exploitable, unauthenticated DoS, yielding a 7.5 score. However, this requires careful contextualisation: exploitation is only possible on hosts actively using the AFS network filesystem client, which is a non-default and relatively niche configuration. This raises practical attack complexity beyond what AC:L implies. EPSS at 0.21% (11th percentile) strongly corroborates the low real-world exploitation likelihood, consistent with the niche deployment footprint of AFS. There is no CISA KEV listing and no public proof-of-concept identified at time of analysis. The impact is strictly availability - a kernel panic causing system reboot - with no confidentiality or integrity exposure. SSVC signals suggest limited automatability at scale given the AFS prerequisite. The gap between the theoretical CVSS severity and the EPSS exploitation probability is notable; this should be patched but is not a fire-drill priority except in AFS-dependent environments.

An attacker who can send crafted AFS RxRPC protocol messages to a Linux host running the AFS client - for example, by acting as a rogue AFS server on the same network or by injecting UDP packets on the relevant port - sends a callback break referencing an unknown volume ID. The kernel's afs_break_some_callbacks() calls afs_lookup_volume_rcu(), receives NULL, and dereferences it without checking, causing a kernel panic and system reboot. No public proof-of-concept is known at time of analysis.