In the Linux kernel, the following vulnerability has been resolved:
afs: Clear stale peer app data after address list changes
afs_fs_probe_fileserver() fetches the current endpoint state under
server->fs_lock, but leaves old_alist as NULL. Consequently,
afs_set_peer_appdata() treats every address list replacement as initial
setup and only binds the new peers; it never unbinds peers removed from
the old list.
An address refresh can therefore proceed as follows. CPU 0 replaces
server S's list and drops Pold without clearing Pold->app_data. The
server destroyer then clears only S's current peers and lets S reach its
RCU callback. After the callback frees S, CPU 1 handles a callback
through an RxRPC connection that still pins Pold, reads Pold->app_data,
and calls afs_use_server() on the freed object.
KASAN reported:
BUG: KASAN: slab-use-after-free in afs_find_server+0x3c/0xa0
Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74
Call Trace:
afs_find_server+0x3c/0xa0
afs_rx_new_call+0x15c/0x390
rxrpc_new_incoming_call+0x97c/0x1730
rxrpc_input_packet.constprop.0+0xd03/0xec0
rxrpc_io_thread+0x967/0x1640
Allocated by task 93:
afs_lookup_server+0x1a7/0x14c0
afs_alloc_server_list+0x43f/0xb60
afs_create_volume+0x923/0x1490
afs_get_tree+0x1c6/0x10a0
Freed by task 0:
kfree+0x131/0x3c0
rcu_core+0x50a/0x1850
Last potentially related work creation:
__call_rcu_common.constprop.0+0x71/0xa10
afs_put_server+0x213/0x2b0
Preserve old->addresses for the peer app-data update so that removed
peers are cleared before the endpoint state is replaced. Also advance
both cursors when the old and new lists share a peer; activating the
old/new comparison without this would otherwise loop forever on the
shared entry.
CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
CVSS Score: 7.5
AV:N - A remote cell operator supplies the changed fileserver address list in the VL address-lookup reply (afs_vl_lookup_addrs -> afs_fs_probe_fileserver). A later incoming RxRPC call over UDP from a dropped peer reaches afs_rx_new_call -> afs_find_server, which dereferences the freed server through the stale peer app_data.
AC:H - Triggering needs a specific order of events: the client refreshes the server's address list and gets a new version, then the server record goes unused and is freed by afs_server_destroyer after the GC delay, while an RxRPC connection still holds the old peer. Only then does a new incoming call hit it. The refresh and teardown timing follow the client's own activity, not the attacker's.
PR:N - The VL reply and the incoming cache-manager call that reaches afs_rx_new_call/afs_find_server are handled before any server identity check. The attacker needs no account on the victim host.
UI:R - The victim must have mounted, or be actively using, a volume from the attacker's AFS cell so that afs_lookup_server and afs_update_server_record run against the attacker's VL server. AFS mounts are not user-namespace mountable.
S:U - The use-after-free happens in the kernel AFS client's afs_server object and stays within the kernel's own security authority. No VM, sandbox or IOMMU boundary is crossed.
C:H - afs_use_server() works on a freed kmalloc'd afs_server reached through the stale peer app_data. If that slab is reclaimed, fields the attacker controls are read as server state, including pointers, which can leak kernel memory.
I:H - afs_use_server() increments the active counter, and the call path then takes references and queues work on the freed afs_server. Writing into a reallocated object gives a memory-corruption primitive that could be used to hijack control flow.
A:H - A slab use-after-free in the krxrpcio I/O thread (see the KASAN report in the commit) can oops or panic the kernel and bring down all AFS and RxRPC service on the host.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
High |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
Required |
Availability Impact |
High |
AV:N - A remote cell operator supplies the changed fileserver address list in the VL address-lookup reply (afs_vl_lookup_addrs -> afs_fs_probe_fileserver). A later incoming RxRPC call over UDP from a dropped peer reaches afs_rx_new_call -> afs_find_server, which dereferences the freed server through the stale peer app_data.
AC:H - Triggering needs a specific order of events: the client refreshes the server's address list and gets a new version, then the server record goes unused and is freed by afs_server_destroyer after the GC delay, while an RxRPC connection still holds the old peer. Only then does a new incoming call hit it. The refresh and teardown timing follow the client's own activity, not the attacker's.
PR:N - The VL reply and the incoming cache-manager call that reaches afs_rx_new_call/afs_find_server are handled before any server identity check. The attacker needs no account on the victim host.
UI:R - The victim must have mounted, or be actively using, a volume from the attacker's AFS cell so that afs_lookup_server and afs_update_server_record run against the attacker's VL server. AFS mounts are not user-namespace mountable.
S:U - The use-after-free happens in the kernel AFS client's afs_server object and stays within the kernel's own security authority. No VM, sandbox or IOMMU boundary is crossed.
C:H - afs_use_server() works on a freed kmalloc'd afs_server reached through the stale peer app_data. If that slab is reclaimed, fields the attacker controls are read as server state, including pointers, which can leak kernel memory.
I:H - afs_use_server() increments the active counter, and the call path then takes references and queues work on the freed afs_server. Writing into a reallocated object gives a memory-corruption primitive that could be used to hijack control flow.
A:H - A slab use-after-free in the krxrpcio I/O thread (see the KASAN report in the commit) can oops or panic the kernel and bring down all AFS and RxRPC service on the host.
CVSS 3.1