Look up another CVE · open CVE-2026-97583 in the interactive tracker
CVE-2026-97583
afs: Clear stale peer app data after address list changes
Published 2026-09-25 (24 days ago) by the Linux kernel CNA. Subsystem fs/afs. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-97583 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/afs/addr_list.c
fs/afs/fs_probe.c
- What this is
- AFS FILESYSTEMMAINTAINERS section matched on fs/afs/ · linux-afs@lists.infradead.org · Supported
- Kernel module
- kafs
Check it on the machine
grep -w CONFIG_AFS_FS /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w kafsPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookworm, trixie, forky, sid, bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_AFS_FS
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-25 (24 days ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.41%, higher than 33.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- fs/afs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.12.101 | 6.12.111 | 3afb988fd041 |
| 6.15 | 6.18.53 | c7f77a11a1e7 |
| 6.15 | 7.2.7 | 7f7f5589d048 |
| 6.15 | 7.3 | ba0623fc19a4 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
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:NAttack vector, network
- 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:HAttack complexity, high
- 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:NPrivileges required, none
- 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:RUser interaction, required
- 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:UScope, unchanged
- 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:HConfidentiality impact, high
- 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:HIntegrity impact, high
- 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:HAvailability impact, high
- 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.