GHSA-4FJ4-GHWR-GJF7
Vulnerability from github – Published: 2025-02-27 21:32 – Updated: 2025-03-05 15:30
VLAI
Details
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>
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-21809"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T20:16:03Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc, afs: Fix peer hash locking vs RCU callback\n\nIn its address list, afs now retains pointers to and refs on one or more\nrxrpc_peer objects. The address list is freed under RCU and at this time,\nit puts the refs on those peers.\n\nNow, when an rxrpc_peer object runs out of refs, it gets removed from the\npeer hash table and, for that, rxrpc has to take a spinlock. However, it\nis now being called from afs\u0027s RCU cleanup, which takes place in BH\ncontext - but it is just taking an ordinary spinlock.\n\nThe put may also be called from non-BH context, and so there exists the\npossibility of deadlock if the BH-based RCU cleanup happens whilst the hash\nspinlock is held. This led to the attached lockdep complaint.\n\nFix this by changing spinlocks of rxnet-\u003epeer_hash_lock back to\nBH-disabling locks.\n\n ================================\n WARNING: inconsistent lock state\n 6.13.0-rc5-build2+ #1223 Tainted: G E\n --------------------------------\n inconsistent {SOFTIRQ-ON-W} -\u003e {IN-SOFTIRQ-W} usage.\n swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes:\n ffff88810babe228 (\u0026rxnet-\u003epeer_hash_lock){+.?.}-{3:3}, at: rxrpc_put_peer+0xcb/0x180\n {SOFTIRQ-ON-W} state was registered at:\n mark_usage+0x164/0x180\n __lock_acquire+0x544/0x990\n lock_acquire.part.0+0x103/0x280\n _raw_spin_lock+0x2f/0x40\n rxrpc_peer_keepalive_worker+0x144/0x440\n process_one_work+0x486/0x7c0\n process_scheduled_works+0x73/0x90\n worker_thread+0x1c8/0x2a0\n kthread+0x19b/0x1b0\n ret_from_fork+0x24/0x40\n ret_from_fork_asm+0x1a/0x30\n irq event stamp: 972402\n hardirqs last enabled at (972402): [\u003cffffffff8244360e\u003e] _raw_spin_unlock_irqrestore+0x2e/0x50\n hardirqs last disabled at (972401): [\u003cffffffff82443328\u003e] _raw_spin_lock_irqsave+0x18/0x60\n softirqs last enabled at (972300): [\u003cffffffff810ffbbe\u003e] handle_softirqs+0x3ee/0x430\n softirqs last disabled at (972313): [\u003cffffffff810ffc54\u003e] __irq_exit_rcu+0x44/0x110\n\n other info that might help us debug this:\n Possible unsafe locking scenario:\n CPU0\n ----\n lock(\u0026rxnet-\u003epeer_hash_lock);\n \u003cInterrupt\u003e\n lock(\u0026rxnet-\u003epeer_hash_lock);\n\n *** DEADLOCK ***\n 1 lock held by swapper/1/0:\n #0: ffffffff83576be0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire+0x7/0x30\n\n stack backtrace:\n CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G E 6.13.0-rc5-build2+ #1223\n Tainted: [E]=UNSIGNED_MODULE\n Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014\n Call Trace:\n \u003cIRQ\u003e\n dump_stack_lvl+0x57/0x80\n print_usage_bug.part.0+0x227/0x240\n valid_state+0x53/0x70\n mark_lock_irq+0xa5/0x2f0\n mark_lock+0xf7/0x170\n mark_usage+0xe1/0x180\n __lock_acquire+0x544/0x990\n lock_acquire.part.0+0x103/0x280\n _raw_spin_lock+0x2f/0x40\n rxrpc_put_peer+0xcb/0x180\n afs_free_addrlist+0x46/0x90 [kafs]\n rcu_do_batch+0x2d2/0x640\n rcu_core+0x2f7/0x350\n handle_softirqs+0x1ee/0x430\n __irq_exit_rcu+0x44/0x110\n irq_exit_rcu+0xa/0x30\n sysvec_apic_timer_interrupt+0x7f/0xa0\n \u003c/IRQ\u003e",
"id": "GHSA-4fj4-ghwr-gjf7",
"modified": "2025-03-05T15:30:51Z",
"published": "2025-02-27T21:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21809"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0e77dd41689637ac4e1b8fe0f27541f373640855"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10ba5a3d57af20e494e0d979d1894260989235dd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/79d458c13056559d49b5e41fbc4b6890e68cf65b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…