CVE-2026-97583: afs: Clear stale peer app data after address list changes
In the Linux kernel, the following vulnerability has been resolved:
afs: Clear stale peer app data after address list changes
afsfsprobefileserver() fetches the current endpoint state under server->fslock, but leaves oldalist as NULL. Consequently, afssetpeerappdata() 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->appdata. 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->appdata, and calls afsuseserver() on the freed object.
KASAN reported:
BUG: KASAN: slab-use-after-free in afsfindserver+0x3c/0xa0 Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74 Call Trace: afsfindserver+0x3c/0xa0 afsrxnewcall+0x15c/0x390 rxrpcnewincomingcall+0x97c/0x1730 rxrpcinputpacket.constprop.0+0xd03/0xec0 rxrpciothread+0x967/0x1640 Allocated by task 93: afslookupserver+0x1a7/0x14c0 afsallocserverlist+0x43f/0xb60 afscreatevolume+0x923/0x1490 afsgettree+0x1c6/0x10a0 Freed by task 0: kfree+0x131/0x3c0 rcucore+0x50a/0x1850 Last potentially related work creation: callrcucommon.constprop.0+0x71/0xa10 afsputserver+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.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this use-after-free to occur?
An AFS server address list must be refreshed so that an old peer is removed, while an RxRPC connection still pins that removed peer. A later callback through that connection can read the stale peer application data after the associated server object has been freed.
Which systems are realistically exposed?
Systems using the Linux kernel AFS client functionality and communicating with AFS file servers are relevant. The described path specifically involves AFS server address-list replacement and RxRPC incoming callback handling.
How can I identify whether this issue has occurred?
The reported symptom is a KASAN slab use-after-free involving afs_find_server, potentially with a call trace through afs_rx_new_call, rxrpc_new_incoming_call, rxrpc_input_packet, and rxrpc_io_thread. The vulnerability description does not provide a configuration check or other definitive detection method.
What does the fix change?
The fix clears stale peer application data when an AFS server address list changes. This ensures peers removed from the old address list are unbound rather than retaining application data that can reference a freed server.