| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2025-21809: rxrpc, afs: Fix peer hash locking vs RCU callback |
| |
| Description |
| =========== |
| |
| 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> |
| |
| The Linux kernel CVE team has assigned CVE-2025-21809 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 6.8 with commit 72904d7b9bfbf2dd146254edea93958bc35bbbfe and fixed in 6.12.13 with commit 10ba5a3d57af20e494e0d979d1894260989235dd |
| Issue introduced in 6.8 with commit 72904d7b9bfbf2dd146254edea93958bc35bbbfe and fixed in 6.13.2 with commit 0e77dd41689637ac4e1b8fe0f27541f373640855 |
| Issue introduced in 6.8 with commit 72904d7b9bfbf2dd146254edea93958bc35bbbfe and fixed in 6.14 with commit 79d458c13056559d49b5e41fbc4b6890e68cf65b |
| Issue introduced in 6.7.3 with commit 056fc740be000d39a7dba700a935f3bbfbc664e6 |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2025-21809 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| net/rxrpc/peer_event.c |
| net/rxrpc/peer_object.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/10ba5a3d57af20e494e0d979d1894260989235dd |
| https://git.kernel.org/stable/c/0e77dd41689637ac4e1b8fe0f27541f373640855 |
| https://git.kernel.org/stable/c/79d458c13056559d49b5e41fbc4b6890e68cf65b |