Linux Kernel up to 6.12.12/6.13.1 rxrpc_peer data authenticity

Summaryinfo

A vulnerability, which was classified as problematic, has been found in Linux Kernel up to 6.12.12/6.13.1. Impacted is the function rxrpc_peer. This manipulation causes data authenticity. This vulnerability is tracked as CVE-2025-21809. No exploit exists. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 6.12.12/6.13.1. It has been declared as problematic. Affected by this vulnerability is the function rxrpc_peer. The manipulation with an unknown input leads to a data authenticity vulnerability. The CWE definition for the vulnerability is CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data. The impact remains unknown. The summary by CVE is:

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){....}-{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: 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

It is possible to read the advisory at git.kernel.org. This vulnerability is known as CVE-2025-21809 since 12/29/2024. The exploitation appears to be difficult. Technical details of the vulnerability are known, but there is no available exploit.

The vulnerability scanner Nessus provides a plugin with the ID 236983 (Ubuntu 24.04 LTS / 24.10 : Linux kernel vulnerabilities (USN-7521-1)), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.12.13, 6.13.2 or 6.14-rc1 eliminates this vulnerability. Applying the patch 10ba5a3d57af20e494e0d979d1894260989235dd/0e77dd41689637ac4e1b8fe0f27541f373640855/79d458c13056559d49b5e41fbc4b6890e68cf65b is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (236983) and CERT Bund (WID-SEC-2025-0461). Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Affected

• Google Container-Optimized OS
• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• SUSE openSUSE
• Open Source Linux Kernel
• Dell Secure Connect Gateway

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.12.0
• 6.12.1
• 6.12.2
• 6.12.3
• 6.12.4
• 6.12.5
• 6.12.6
• 6.12.7
• 6.12.8
• 6.12.9
• 6.12.10
• 6.12.11
• 6.12.12
• 6.13.0
• 6.13.1

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion