CVE-2026-97584

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

afs_lookup_server() is reached through afs_create_volume()/afs_update_volume_state() -> afs_alloc_server_list() when a local process walks a kAFS path (for example /afs/<cell>/<vol> automount) or uses a volume. Nothing malformed comes off the wire. The defect is local cleanup logic that frees the wrong object, so the attacker needs a local account on the AFS client.

AC:LAttack complexity, low

The candidate is left non-NULL when afs_install_server() returns an existing record. That happens when the attacker runs parallel lookups of volumes on the same fileserver UUID, or accesses the path again after a creation attempt failed and left the record marked UNCREATED. Both states come from the attacker's own path accesses; neither depends on outside conditions.

PR:LPrivileges required, low

Mounting kAFS needs CAP_SYS_ADMIN (no FS_USERNS_MOUNT). On a client that already has the /afs dynroot mounted, any unprivileged user can start the volume and server lookups that reach afs_lookup_server() just by accessing /afs/<cell>/... paths.

UI:NUser interaction, none

No victim action is needed; the attacker triggers the lookups and the faulty cleanup with their own filesystem accesses.

S:UScope, unchanged

The memory corruption stays inside the kernel's own security authority; no VM, IOMMU or sandbox boundary is crossed.

C:HConfidentiality impact, high

The cleanup at the out: label kfree()s the existing server's live, refcounted afs_endpoint_state. server->endpoint_state and in-flight probe/rotate operations still reference it, giving a use-after-free of a sprayable kmalloc object that can be reclaimed to leak kernel data.

I:HIntegrity impact, high

After the bad kfree(), afs_put_endpoint_state() and the probe code keep writing refcounts, flags and the addresses pointer into the freed estate. When the refcount later drops to zero it is freed a second time via call_rcu, so a reclaimed object gets corrupted.

A:HAvailability impact, high

The freed estate is later used and double-freed, and on the create_failed and wait_for_creation failure paths `server` is NULL when server->endpoint_state is read. Either way the kernel oopses or panics.