CVE-2025-21809: rxrpc, afs: Fix peer hash locking vs RCU callback
In the Linux kernel, the following vulnerability has been resolved:
rxrpc, afs: Fix peer hash locking vs RCU callback
In its address list, afs now retains pointers to and refs on one or more
rxrpc_peer objects. The address list is freed under RCU and at this time,
it puts the refs on those peers.
Now, when an rxrpc_peer object runs out of refs, it gets removed from the
peer hash table and, for that, rxrpc has to take a spinlock. However, it
is now being called from afs's RCU cleanup, which takes place in BH
context - but it is just taking an ordinary spinlock.
The put may also be called from non-BH context, and so there exists the
possibility of deadlock if the BH-based RCU cleanup happens whilst the hash
spinlock is held. This led to the attached lockdep complaint.
Fix this by changing spinlocks of rxnet->peer_hash_lock back to
BH-disabling locks.
================================
WARNING: inconsistent lock state
6.13.0-rc5-build2+ #1223 Tainted: G E
--------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
ffff88810babe228 (&rxnet->peer_hash_lock){+.?.}-{3:3}, at: rxrpc_put_peer+0xcb/0x180
{SOFTIRQ-ON-W} state was registered at:
mark_usage+0x164/0x180
__lock_acquire+0x544/0x990
lock_acquire.part.0+0x103/0x280
_raw_spin_lock+0x2f/0x40
rxrpc_peer_keepalive_worker+0x144/0x440
process_one_work+0x486/0x7c0
process_scheduled_works+0x73/0x90
worker_thread+0x1c8/0x2a0
kthread+0x19b/0x1b0
ret_from_fork+0x24/0x40
ret_from_fork_asm+0x1a/0x30
irq event stamp: 972402
hardirqs last enabled at (972402): [<ffffffff8244360e>] _raw_spin_unlock_irqrestore+0x2e/0x50
hardirqs last disabled at (972401): [<ffffffff82443328>] _raw_spin_lock_irqsave+0x18/0x60
softirqs last enabled at (972300): [<ffffffff810ffbbe>] handle_softirqs+0x3ee/0x430
softirqs last disabled at (972313): [<ffffffff810ffc54>] __irq_exit_rcu+0x44/0x110
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&rxnet->peer_hash_lock);
<Interrupt>
lock(&rxnet->peer_hash_lock);
*** DEADLOCK ***
1 lock held by swapper/1/0:
#0: ffffffff83576be0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire+0x7/0x30
stack backtrace:
CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G E 6.13.0-rc5-build2+ #1223
Tainted: [E]=UNSIGNED_MODULE
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
Call Trace:
<IRQ>
dump_stack_lvl+0x57/0x80
print_usage_bug.part.0+0x227/0x240
valid_state+0x53/0x70
mark_lock_irq+0xa5/0x2f0
mark_lock+0xf7/0x170
mark_usage+0xe1/0x180
__lock_acquire+0x544/0x990
lock_acquire.part.0+0x103/0x280
_raw_spin_lock+0x2f/0x40
rxrpc_put_peer+0xcb/0x180
afs_free_addrlist+0x46/0x90 [kafs]
rcu_do_batch+0x2d2/0x640
rcu_core+0x2f7/0x350
handle_softirqs+0x1ee/0x430
__irq_exit_rcu+0x44/0x110
irq_exit_rcu+0xa/0x30
sysvec_apic_timer_interrupt+0x7f/0xa0
</IRQ>
Security readout for executives and security teams
Plain-English summary
CVE-2025-21809 is a Linux kernel locking bug in rxrpc/AFS handling. Under certain local conditions, the kernel can deadlock while cleaning up peer references, causing availability impact. The published CVSS is 5.5 medium, with local access and low privileges required.
Executive priority
Treat as a moderate availability issue. Patch through normal kernel maintenance, with higher priority for systems using AFS/rxrpc or where local-user denial of service would affect critical services.
Technical view
AFS address-list cleanup runs under RCU in BH context and may release rxrpc_peer references. rxrpc_put_peer removes peers from a hash table using peer_hash_lock. The lock was taken inconsistently between normal and softirq contexts, creating a deadlock risk. The fix changes rxnet->peer_hash_lock back to BH-disabling locking.
Likely exposure
Exposure is limited to Linux systems running affected kernel versions with relevant rxrpc/AFS code present or reachable. The bundle lists Linux as affected, including versions 6.8, 6.12.13, 6.13.2, and 6.14, but organizations should confirm exact distro backports.
Exploitation context
The source bundle does not report active exploitation, and KEV is false. CVSS indicates local attack vector, low privileges, no user interaction, and high availability impact. Evidence supports denial-of-service risk, not data theft or integrity compromise.
Researcher notes
The evidence is a resolved Linux kernel concurrency flaw, not a published exploit. Analysis should focus on kernel version lineage, distro backports, and whether local users can exercise AFS/rxrpc paths. Avoid assuming remote reachability from the available sources.
Mitigation direction
Apply vendor kernel updates incorporating the referenced stable fixes.
For custom kernels, include the upstream stable peer_hash_lock BH-locking fix.
Prioritize hosts using AFS or rxrpc-dependent workloads.
Check Linux distribution advisories for backported fixed package versions.
Schedule reboots where required to load the corrected kernel.
Validation and detection
Inventory running Linux kernel versions across exposed fleets.
Confirm whether AFS or rxrpc kernel components are enabled or loaded.
Compare installed kernels with vendor-fixed versions or referenced stable commits.
Review kernel logs for lockdep warnings or unexplained deadlocks.
Verify rebooted systems are running the updated kernel.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-667: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-667 · source CWE mapping
Improper Locking
Improper Locking represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.