Linux Kernel CVE-2026-97584

Requires the host to have the Linux kernel AFS (kAFS/AndrewFS) client in use with an AFS filesystem mounted, so that afs_lookup_server() is exercised; the erroneous free occurs during candidate-server cleanup and is reached via concurrent/racing server-lookup activity. Limiting factors: local execution context only (no network-remote trigger of the described free), the code path is confined to AFS deployments (a rare configuration), and the practical result is a kernel crash rather than controllable memory corruption. Affected kernels are those from ~6.15 up to the fixed 6.12.111/6.18.53/7.2.7/7.3-rc3 releases.

This is a NVD-scored 7.8 HIGH, but the CVSS vector (AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H) overstates real-world risk. The flaw is an incorrect free in afs_lookup_server(): the candidate-server cleanup path frees an EXISTING server's endpoint state even though the candidate record does not yet have one, causing a use-after-free / erroneous free of another server's afs_endpoint_state. This is a kernel-internal memory-management bug in the AFS network-filesystem client, triggered by concurrent server-lookup activity on a mounted AFS filesystem - not by attacker-supplied data with fine-grained control, so the realistic outcome is a KASAN-detected crash (DoS) rather than reliable info disclosure or code execution. The claimed C:H/I:H is not supported by the description, which describes a cleanup logic error; C:N/I:L is more defensible. There is NO EPSS score, NO CISA KEV listing, and NO public exploit - no exploitation signals whatsoever. SSVC is not provided. Net: no public exploit identified at time of analysis; treat as a routine kernel hardening/DoS fix, low real-world priority outside AFS-using environments.

On a host actively using an AFS (AndrewFS) mount, concurrent afs_lookup_server() operations create a candidate server record and, during cleanup, erroneously free the endpoint state belonging to an already-existing server, leading to a use-after-free/double-free that panics the kernel. No public exploit code exists, and exploitation requires local activity against a mounted AFS filesystem rather than a remote crafted request.