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 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>

This vulnerability is rated as Moderate impact because exploitation requires local access or initiation of in-kernel AFS operations, restricting the blast radius to a denial of service without compromising confidentiality or integrity. In default Red Hat Enterprise Linux installations, the AFS filesystem and RxRPC protocol modules are not loaded or active unless explicitly configured. Consequently, only systems actively utilizing in-kernel AFS network mounts or RxRPC communication are exposed to potential system deadlocks.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.