In the Linux kernel, the following vulnerability has been resolved:
afs: Fix incorrect free in candidate cleanup in afs_lookup_server()
Fix afs_lookup_server() to not free an existing server's endpoint state
when cleaning up a candidate server. The candidate record doesn't have an
endpoint state yet at this point, so the free for that can just be removed.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - 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:L - 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:L - 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:N - No victim action is needed; the attacker triggers the lookups and the faulty cleanup with their own filesystem accesses.
S:U - The memory corruption stays inside the kernel's own security authority; no VM, IOMMU or sandbox boundary is crossed.
C:H - 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:H - 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:H - 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.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - 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:L - 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:L - 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:N - No victim action is needed; the attacker triggers the lookups and the faulty cleanup with their own filesystem accesses.
S:U - The memory corruption stays inside the kernel's own security authority; no VM, IOMMU or sandbox boundary is crossed.
C:H - 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:H - 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:H - 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.
CVSS 3.1