cbcvebase.
CVE-2025-21809
published 2025-02-27

CVE-2025-21809: 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…

PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.30%
22.2th percentile
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): [] _raw_spin_unlock_irqrestore+0x2e/0x50 hardirqs last disabled at (972401): [] _raw_spin_lock_irqsave+0x18/0x60 softirqs last enabled at (972300): [] handle_softirqs+0x3ee/0x430 softirqs last disabled at (972313): [] __irq_exit_rcu+0x44/0x110 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&rxnet->peer_hash_lock); lock(&rxnet->peer_hash_lock); *** DEADLOCK *** 1 lock held by swapper/1/0: #0: ffffffff83576be0 (rcu_callback){

Affected

12 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.12.13-1 (forky)linux 6.12.13-1 (forky)
linuxlinux
linuxlinux
linuxlinux>= 6.7.3 < 6.86.8
linuxlinux>= 72904d7b9bfbf2dd146254edea93958bc35bbbfe < 10ba5a3d57af20e494e0d979d1894260989235dd10ba5a3d57af20e494e0d979d1894260989235dd
linuxlinux>= 72904d7b9bfbf2dd146254edea93958bc35bbbfe < 0e77dd41689637ac4e1b8fe0f27541f3736408550e77dd41689637ac4e1b8fe0f27541f373640855
linuxlinux>= 72904d7b9bfbf2dd146254edea93958bc35bbbfe < 79d458c13056559d49b5e41fbc4b6890e68cf65b79d458c13056559d49b5e41fbc4b6890e68cf65b
linuxlinux_kernel>= 0 < 6.12.13-16.12.13-1
linuxlinux_kernel>= 0 < 6.12.13-16.12.13-1
linuxlinux_kernel>= 0 < 6.8.0-64.676.8.0-64.67
linuxlinux_kernel>= 6.13 < 6.13.26.13.2
linuxlinux_kernel>= 6.7.3 < 6.12.136.12.13

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv7.8HIGH
vendor_ubuntu7.8HIGH
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.