Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-25T11:17:09.127Z",
  "pubdate": "2026-09-25T11:17:09.127Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel AFS (Andrew File System) implementation due to improper management of peer application data during address list updates.\nThe vulnerability occurs because removed server peers are not correctly unbound or cleared when an address list is replaced, leaving stale pointers in the system.\nThis flaw can be triggered when a network callback occurs on an RxRPC connection pinning a freed peer, leading to a kernel-level use-after-free condition.\nThe impact is a high-severity kernel memory corruption or crash, potentially allowing for arbitrary code execution or local privilege escalation depending on the system state.\nExploitation requires the attacker to influence AFS network operations to trigger server list updates and subsequent callback processing, making it a race condition dependent on specific network activity patterns.\nThe issue affects the Linux kernel's AFS component, where improper reference tracking during the lifecycle of file server objects leads to premature object release while external references still exist.",
  "technicalDetails": "The root cause is located in the interaction between afs_fs_probe_fileserver() and afs_set_peer_appdata(). During an address list replacement, afs_fs_probe_fileserver() fetches the current endpoint state under server->fs_lock but fails to track the previous address list (old_alist).\nConsequently, afs_set_peer_appdata() incorrectly treats every list replacement as an initial setup phase. It binds the new peers but fails to unbind peers that were removed from the old list. This results in stale pointers being held by existing RxRPC connections that continue to reference the defunct peer application data.\nThe attack flow follows a specific sequence of operations: First, CPU 0 updates server S's address list and removes peer Pold. Because the cleanup logic is flawed, Pold->app_data remains set. Subsequently, the server destroyer clears only the current peers of S and triggers the RCU callback, which eventually frees server S.\nFollowing the freeing of the server object, a concurrent process on CPU 1 handles an incoming network callback through an RxRPC connection that still holds a reference to Pold. When the kernel attempts to process this callback, it reads the stale Pold->app_data and executes afs_use_server() on the already freed object.\nThis triggers a slab-use-after-free condition, as confirmed by KASAN reports showing a read operation on address ffff8881013e1af0 originating from afs_find_server(). The flaw demonstrates that the kernel fails to synchronize the teardown of peer application metadata with the lifecycle of the server object.\nThe vulnerability persists because the kernel lacks a mechanism to verify the validity of the peer's application data pointer once the server structure has been scheduled for reclamation. Without the explicit clearing of old peer data, any dangling reference held by the RxRPC layer becomes a target for a use-after-free exploit.\nThe remediation involves modifying the address update logic to preserve access to the old address list during the transition. By correctly iterating over both the old and new lists, the system can ensure that removed peers are properly unbound before the endpoint state is overwritten, thereby preventing the retention of stale pointers."
}