CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
753 vulnerabilities reference this CWE, most recent first.
GHSA-4FJ4-GHWR-GJF7
Vulnerability from github – Published: 2025-02-27 21:32 – Updated: 2025-03-05 15:30In 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>
{
"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"
}
]
}
GHSA-4GG5-G35C-MGHX
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-09-26 15:30In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Define the __io_aw() hook as mmiowb()
Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says:
"NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation."
The mmio in radeon_ring_commit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio.
So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the __io_aw() hook as mmiowb(). And we no longer need to override queued_spin_unlock() so use the generic definition.
Without this, we get such an error when run 'glxgears' on weak ordering architectures such as LoongArch:
radeon 0000:04:00.0: ring 0 stalled for more than 10324msec radeon 0000:04:00.0: ring 3 stalled for more than 10240msec radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3) radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35)
{
"affected": [],
"aliases": [
"CVE-2024-35818"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Define the __io_aw() hook as mmiowb()\n\nCommit fb24ea52f78e0d595852e (\"drivers: Remove explicit invocations of\nmmiowb()\") remove all mmiowb() in drivers, but it says:\n\n\"NOTE: mmiowb() has only ever guaranteed ordering in conjunction with\nspin_unlock(). However, pairing each mmiowb() removal in this patch with\nthe corresponding call to spin_unlock() is not at all trivial, so there\nis a small chance that this change may regress any drivers incorrectly\nrelying on mmiowb() to order MMIO writes between CPUs using lock-free\nsynchronisation.\"\n\nThe mmio in radeon_ring_commit() is protected by a mutex rather than a\nspinlock, but in the mutex fastpath it behaves similar to spinlock. We\ncan add mmiowb() calls in the radeon driver but the maintainer says he\ndoesn\u0027t like such a workaround, and radeon is not the only example of\nmutex protected mmio.\n\nSo we should extend the mmiowb tracking system from spinlock to mutex,\nand maybe other locking primitives. This is not easy and error prone, so\nwe solve it in the architectural code, by simply defining the __io_aw()\nhook as mmiowb(). And we no longer need to override queued_spin_unlock()\nso use the generic definition.\n\nWithout this, we get such an error when run \u0027glxgears\u0027 on weak ordering\narchitectures such as LoongArch:\n\nradeon 0000:04:00.0: ring 0 stalled for more than 10324msec\nradeon 0000:04:00.0: ring 3 stalled for more than 10240msec\nradeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3)\nradeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0027t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0027t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0027t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0027t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0027t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0027t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0027t update BO_VA (-35)",
"id": "GHSA-4gg5-g35c-mghx",
"modified": "2025-09-26T15:30:22Z",
"published": "2024-05-17T15:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35818"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b61a7dc6712b78799b3949997e8a5e94db5c4b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/97cd43ba824aec764f5ea2790d0c0a318f885167"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9adec248bba33b1503252caf8e59d81febfc5ceb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c68ece8b2a5c5ff9b2fcaea923dd73efeb174cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7d7c6cdea875be3b241d7d39873bb431db7154d"
}
],
"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"
}
]
}
GHSA-4GJR-XFFJ-592Q
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-06-03 18:55In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in port "disable" sysfs attribute
The show and store callback routines for the "disable" sysfs attribute file in port.c acquire the device lock for the port's parent hub device. This can cause problems if another process has locked the hub to remove it or change its configuration:
Removing the hub or changing its configuration requires the
hub interface to be removed, which requires the port device
to be removed, and device_del() waits until all outstanding
sysfs attribute callbacks for the ports have returned. The
lock can't be released until then.
But the disable_show() or disable_store() routine can't return
until after it has acquired the lock.
The resulting deadlock can be avoided by calling sysfs_break_active_protection(). This will cause the sysfs core not to wait for the attribute's callback routine to return, allowing the removal to proceed. The disadvantage is that after making this call, there is no guarantee that the hub structure won't be deallocated at any moment. To prevent this, we have to acquire a reference to it first by calling hub_get().
{
"affected": [],
"aliases": [
"CVE-2024-26933"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:07Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Fix deadlock in port \"disable\" sysfs attribute\n\nThe show and store callback routines for the \"disable\" sysfs attribute\nfile in port.c acquire the device lock for the port\u0027s parent hub\ndevice. This can cause problems if another process has locked the hub\nto remove it or change its configuration:\n\n\tRemoving the hub or changing its configuration requires the\n\thub interface to be removed, which requires the port device\n\tto be removed, and device_del() waits until all outstanding\n\tsysfs attribute callbacks for the ports have returned. The\n\tlock can\u0027t be released until then.\n\n\tBut the disable_show() or disable_store() routine can\u0027t return\n\tuntil after it has acquired the lock.\n\nThe resulting deadlock can be avoided by calling\nsysfs_break_active_protection(). This will cause the sysfs core not\nto wait for the attribute\u0027s callback routine to return, allowing the\nremoval to proceed. The disadvantage is that after making this call,\nthere is no guarantee that the hub structure won\u0027t be deallocated at\nany moment. To prevent this, we have to acquire a reference to it\nfirst by calling hub_get().",
"id": "GHSA-4gjr-xffj-592q",
"modified": "2024-06-03T18:55:50Z",
"published": "2024-05-01T06:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26933"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4facc9421117ba9d8148c73771b213887fec77f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/73d1589b91f2099e5f6534a8497b7c6b527e064e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9dac54f08198147f5ec0ec52fcf1bc8ac899ac05"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f4d1960764d8a70318b02f15203a1be2b2554ca1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f51849833705dea5b4f9b0c8de714dd87bd6c95c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4GQC-44F8-FCVG
Vulnerability from github – Published: 2024-04-17 12:32 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Fix a deadlock issue related to automatic dump
If we issue a disabling PHY command, the device attached with it will go offline, if a 2 bit ECC error occurs at the same time, a hung task may be found:
[ 4613.652388] INFO: task kworker/u256:0:165233 blocked for more than 120 seconds. [ 4613.666297] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4613.674809] task:kworker/u256:0 state:D stack: 0 pid:165233 ppid: 2 flags:0x00000208 [ 4613.683959] Workqueue: 0000:74:02.0_disco_q sas_revalidate_domain [libsas] [ 4613.691518] Call trace: [ 4613.694678] __switch_to+0xf8/0x17c [ 4613.698872] __schedule+0x660/0xee0 [ 4613.703063] schedule+0xac/0x240 [ 4613.706994] schedule_timeout+0x500/0x610 [ 4613.711705] __down+0x128/0x36c [ 4613.715548] down+0x240/0x2d0 [ 4613.719221] hisi_sas_internal_abort_timeout+0x1bc/0x260 [hisi_sas_main] [ 4613.726618] sas_execute_internal_abort+0x144/0x310 [libsas] [ 4613.732976] sas_execute_internal_abort_dev+0x44/0x60 [libsas] [ 4613.739504] hisi_sas_internal_task_abort_dev.isra.0+0xbc/0x1b0 [hisi_sas_main] [ 4613.747499] hisi_sas_dev_gone+0x174/0x250 [hisi_sas_main] [ 4613.753682] sas_notify_lldd_dev_gone+0xec/0x2e0 [libsas] [ 4613.759781] sas_unregister_common_dev+0x4c/0x7a0 [libsas] [ 4613.765962] sas_destruct_devices+0xb8/0x120 [libsas] [ 4613.771709] sas_do_revalidate_domain.constprop.0+0x1b8/0x31c [libsas] [ 4613.778930] sas_revalidate_domain+0x60/0xa4 [libsas] [ 4613.784716] process_one_work+0x248/0x950 [ 4613.789424] worker_thread+0x318/0x934 [ 4613.793878] kthread+0x190/0x200 [ 4613.797810] ret_from_fork+0x10/0x18 [ 4613.802121] INFO: task kworker/u256:4:316722 blocked for more than 120 seconds. [ 4613.816026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4613.824538] task:kworker/u256:4 state:D stack: 0 pid:316722 ppid: 2 flags:0x00000208 [ 4613.833670] Workqueue: 0000:74:02.0 hisi_sas_rst_work_handler [hisi_sas_main] [ 4613.841491] Call trace: [ 4613.844647] __switch_to+0xf8/0x17c [ 4613.848852] __schedule+0x660/0xee0 [ 4613.853052] schedule+0xac/0x240 [ 4613.856984] schedule_timeout+0x500/0x610 [ 4613.861695] __down+0x128/0x36c [ 4613.865542] down+0x240/0x2d0 [ 4613.869216] hisi_sas_controller_prereset+0x58/0x1fc [hisi_sas_main] [ 4613.876324] hisi_sas_rst_work_handler+0x40/0x8c [hisi_sas_main] [ 4613.883019] process_one_work+0x248/0x950 [ 4613.887732] worker_thread+0x318/0x934 [ 4613.892204] kthread+0x190/0x200 [ 4613.896118] ret_from_fork+0x10/0x18 [ 4613.900423] INFO: task kworker/u256:1:348985 blocked for more than 121 seconds. [ 4613.914341] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4613.922852] task:kworker/u256:1 state:D stack: 0 pid:348985 ppid: 2 flags:0x00000208 [ 4613.931984] Workqueue: 0000:74:02.0_event_q sas_port_event_worker [libsas] [ 4613.939549] Call trace: [ 4613.942702] __switch_to+0xf8/0x17c [ 4613.946892] __schedule+0x660/0xee0 [ 4613.951083] schedule+0xac/0x240 [ 4613.955015] schedule_timeout+0x500/0x610 [ 4613.959725] wait_for_common+0x200/0x610 [ 4613.964349] wait_for_completion+0x3c/0x5c [ 4613.969146] flush_workqueue+0x198/0x790 [ 4613.973776] sas_porte_broadcast_rcvd+0x1e8/0x320 [libsas] [ 4613.979960] sas_port_event_worker+0x54/0xa0 [libsas] [ 4613.985708] process_one_work+0x248/0x950 [ 4613.990420] worker_thread+0x318/0x934 [ 4613.994868] kthread+0x190/0x200 [ 4613.998800] ret_from_fork+0x10/0x18
This is because when the device goes offline, we obtain the hisi_hba semaphore and send the ABORT_DEV command to the device. However, the internal abort timed out due to the 2 bit ECC error and triggers automatic dump. In addition, since the hisi_hba semaphore has been obtained, the dump cannot be executed and the controller cannot be reset.
Therefore, the deadlocks occur on the following circular dependencies ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26873"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T11:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Fix a deadlock issue related to automatic dump\n\nIf we issue a disabling PHY command, the device attached with it will go\noffline, if a 2 bit ECC error occurs at the same time, a hung task may be\nfound:\n\n[ 4613.652388] INFO: task kworker/u256:0:165233 blocked for more than 120 seconds.\n[ 4613.666297] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 4613.674809] task:kworker/u256:0 state:D stack: 0 pid:165233 ppid: 2 flags:0x00000208\n[ 4613.683959] Workqueue: 0000:74:02.0_disco_q sas_revalidate_domain [libsas]\n[ 4613.691518] Call trace:\n[ 4613.694678] __switch_to+0xf8/0x17c\n[ 4613.698872] __schedule+0x660/0xee0\n[ 4613.703063] schedule+0xac/0x240\n[ 4613.706994] schedule_timeout+0x500/0x610\n[ 4613.711705] __down+0x128/0x36c\n[ 4613.715548] down+0x240/0x2d0\n[ 4613.719221] hisi_sas_internal_abort_timeout+0x1bc/0x260 [hisi_sas_main]\n[ 4613.726618] sas_execute_internal_abort+0x144/0x310 [libsas]\n[ 4613.732976] sas_execute_internal_abort_dev+0x44/0x60 [libsas]\n[ 4613.739504] hisi_sas_internal_task_abort_dev.isra.0+0xbc/0x1b0 [hisi_sas_main]\n[ 4613.747499] hisi_sas_dev_gone+0x174/0x250 [hisi_sas_main]\n[ 4613.753682] sas_notify_lldd_dev_gone+0xec/0x2e0 [libsas]\n[ 4613.759781] sas_unregister_common_dev+0x4c/0x7a0 [libsas]\n[ 4613.765962] sas_destruct_devices+0xb8/0x120 [libsas]\n[ 4613.771709] sas_do_revalidate_domain.constprop.0+0x1b8/0x31c [libsas]\n[ 4613.778930] sas_revalidate_domain+0x60/0xa4 [libsas]\n[ 4613.784716] process_one_work+0x248/0x950\n[ 4613.789424] worker_thread+0x318/0x934\n[ 4613.793878] kthread+0x190/0x200\n[ 4613.797810] ret_from_fork+0x10/0x18\n[ 4613.802121] INFO: task kworker/u256:4:316722 blocked for more than 120 seconds.\n[ 4613.816026] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 4613.824538] task:kworker/u256:4 state:D stack: 0 pid:316722 ppid: 2 flags:0x00000208\n[ 4613.833670] Workqueue: 0000:74:02.0 hisi_sas_rst_work_handler [hisi_sas_main]\n[ 4613.841491] Call trace:\n[ 4613.844647] __switch_to+0xf8/0x17c\n[ 4613.848852] __schedule+0x660/0xee0\n[ 4613.853052] schedule+0xac/0x240\n[ 4613.856984] schedule_timeout+0x500/0x610\n[ 4613.861695] __down+0x128/0x36c\n[ 4613.865542] down+0x240/0x2d0\n[ 4613.869216] hisi_sas_controller_prereset+0x58/0x1fc [hisi_sas_main]\n[ 4613.876324] hisi_sas_rst_work_handler+0x40/0x8c [hisi_sas_main]\n[ 4613.883019] process_one_work+0x248/0x950\n[ 4613.887732] worker_thread+0x318/0x934\n[ 4613.892204] kthread+0x190/0x200\n[ 4613.896118] ret_from_fork+0x10/0x18\n[ 4613.900423] INFO: task kworker/u256:1:348985 blocked for more than 121 seconds.\n[ 4613.914341] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 4613.922852] task:kworker/u256:1 state:D stack: 0 pid:348985 ppid: 2 flags:0x00000208\n[ 4613.931984] Workqueue: 0000:74:02.0_event_q sas_port_event_worker [libsas]\n[ 4613.939549] Call trace:\n[ 4613.942702] __switch_to+0xf8/0x17c\n[ 4613.946892] __schedule+0x660/0xee0\n[ 4613.951083] schedule+0xac/0x240\n[ 4613.955015] schedule_timeout+0x500/0x610\n[ 4613.959725] wait_for_common+0x200/0x610\n[ 4613.964349] wait_for_completion+0x3c/0x5c\n[ 4613.969146] flush_workqueue+0x198/0x790\n[ 4613.973776] sas_porte_broadcast_rcvd+0x1e8/0x320 [libsas]\n[ 4613.979960] sas_port_event_worker+0x54/0xa0 [libsas]\n[ 4613.985708] process_one_work+0x248/0x950\n[ 4613.990420] worker_thread+0x318/0x934\n[ 4613.994868] kthread+0x190/0x200\n[ 4613.998800] ret_from_fork+0x10/0x18\n\nThis is because when the device goes offline, we obtain the hisi_hba\nsemaphore and send the ABORT_DEV command to the device. However, the\ninternal abort timed out due to the 2 bit ECC error and triggers automatic\ndump. In addition, since the hisi_hba semaphore has been obtained, the dump\ncannot be executed and the controller cannot be reset.\n\nTherefore, the deadlocks occur on the following circular dependencies\n---truncated---",
"id": "GHSA-4gqc-44f8-fcvg",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-04-17T12:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26873"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c4f53b2c341ec6428b98cb51a89a09b025d0953"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85c98073ffcfe9e46abfb9c66f3364467119d563"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a47f0b03149af538af4442ff0702eac430ace1cb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e022dd3b875315a2d2001a512e98d1dc8c991f4a"
}
],
"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"
}
]
}
GHSA-4H52-R3P6-R457
Vulnerability from github – Published: 2026-09-30 18:33 – Updated: 2026-09-30 18:33NVIDIA GPU Display Driver for Windows contains a vulnerability in the kernel module where a user could cause improper locking. A successful exploit of this vulnerability might lead to denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-47581"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-30T16:17:27Z",
"severity": "MODERATE"
},
"details": "NVIDIA GPU Display Driver for Windows contains a vulnerability in the kernel module where a user could cause improper locking. A successful exploit of this vulnerability might lead to denial of service.",
"id": "GHSA-4h52-r3p6-r457",
"modified": "2026-09-30T18:33:46Z",
"published": "2026-09-30T18:33:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47581"
},
{
"type": "WEB",
"url": "https://github.com/NVIDIA/product-security/tree/main/2026/5861"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47581"
}
],
"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"
}
]
}
GHSA-4J23-W98Q-23FX
Vulnerability from github – Published: 2025-10-23 12:31 – Updated: 2025-10-23 12:31In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Fix sleep from invalid context BUG
Taking the qos_mutex to process RoCEv2 QP's on netdev events causes a kernel splat.
Fix this by removing the handling for RoCEv2 in irdma_cm_teardown_connections that uses the mutex. This handling is only needed for iWARP to avoid having connections established while the link is down or having connections remain functional after the IP address is removed.
BUG: sleeping function called from invalid context at kernel/locking/mutex. Call Trace: kernel: dump_stack+0x66/0x90 kernel: ___might_sleep.cold.92+0x8d/0x9a kernel: mutex_lock+0x1c/0x40 kernel: irdma_cm_teardown_connections+0x28e/0x4d0 [irdma] kernel: ? check_preempt_curr+0x7a/0x90 kernel: ? select_idle_sibling+0x22/0x3c0 kernel: ? select_task_rq_fair+0x94c/0xc90 kernel: ? irdma_exec_cqp_cmd+0xc27/0x17c0 [irdma] kernel: ? __wake_up_common+0x7a/0x190 kernel: irdma_if_notify+0x3cc/0x450 [irdma] kernel: ? sched_clock_cpu+0xc/0xb0 kernel: irdma_inet6addr_event+0xc6/0x150 [irdma]
{
"affected": [],
"aliases": [
"CVE-2022-49606"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:36Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/irdma: Fix sleep from invalid context BUG\n\nTaking the qos_mutex to process RoCEv2 QP\u0027s on netdev events causes a\nkernel splat.\n\nFix this by removing the handling for RoCEv2 in\nirdma_cm_teardown_connections that uses the mutex. This handling is only\nneeded for iWARP to avoid having connections established while the link is\ndown or having connections remain functional after the IP address is\nremoved.\n\n BUG: sleeping function called from invalid context at kernel/locking/mutex.\n Call Trace:\n kernel: dump_stack+0x66/0x90\n kernel: ___might_sleep.cold.92+0x8d/0x9a\n kernel: mutex_lock+0x1c/0x40\n kernel: irdma_cm_teardown_connections+0x28e/0x4d0 [irdma]\n kernel: ? check_preempt_curr+0x7a/0x90\n kernel: ? select_idle_sibling+0x22/0x3c0\n kernel: ? select_task_rq_fair+0x94c/0xc90\n kernel: ? irdma_exec_cqp_cmd+0xc27/0x17c0 [irdma]\n kernel: ? __wake_up_common+0x7a/0x190\n kernel: irdma_if_notify+0x3cc/0x450 [irdma]\n kernel: ? sched_clock_cpu+0xc/0xb0\n kernel: irdma_inet6addr_event+0xc6/0x150 [irdma]",
"id": "GHSA-4j23-w98q-23fx",
"modified": "2025-10-23T12:31:15Z",
"published": "2025-10-23T12:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49606"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cae7e519032e4b4672cb9204d5586a441924364"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4c5115140ed1833197bad9a6b80265840ff427f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc0315564d6eec91c716d314b743321be24c70b3"
}
],
"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"
}
]
}
GHSA-4J2M-GFQM-629P
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-28 09:31In the Linux kernel, the following vulnerability has been resolved:
dm cache policy smq: fix missing locks in invalidating cache blocks
In passthrough mode, the policy invalidate_mapping operation is called simultaneously from multiple workers, thus it should be protected by a lock. Otherwise, we might end up with data races on the allocated blocks counter, or even use-after-free issues with internal data structures when doing concurrent writes.
Note that the existing FIXME in smq_invalidate_mapping() doesn't affect passthrough mode since migration tasks don't exist there, but would need attention if supporting fast device shrinking via suspend/resume without target reloading.
Reproduce steps:
- Create a cache device consisting of 1024 cache entries
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
- Populate the cache, and record the number of cached blocks
fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --size=64m --direct=1 nr_cached=$(dmsetup status cache | awk '{split($7, a, "/"); print a[1]}')
- Reload the cache into passthrough mode
dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache
- Write to the passthrough cache. By setting multiple jobs with I/O size equal to the cache block size, cache blocks are invalidated concurrently from different workers.
fio --filename=/dev/mapper/cache --name=test --rw=randwrite --bs=64k \ --direct=1 --numjobs=2 --randrepeat=0 --size=64m
- Check if demoted matches cached block count. These numbers should match but may differ due to the data race.
nr_demoted=$(dmsetup status cache | awk '{print $12}') echo "$nr_cached, $nr_demoted"
{
"affected": [],
"aliases": [
"CVE-2026-53062"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:19Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm cache policy smq: fix missing locks in invalidating cache blocks\n\nIn passthrough mode, the policy invalidate_mapping operation is called\nsimultaneously from multiple workers, thus it should be protected by a\nlock. Otherwise, we might end up with data races on the allocated blocks\ncounter, or even use-after-free issues with internal data structures\nwhen doing concurrent writes.\n\nNote that the existing FIXME in smq_invalidate_mapping() doesn\u0027t affect\npassthrough mode since migration tasks don\u0027t exist there, but would need\nattention if supporting fast device shrinking via suspend/resume without\ntarget reloading.\n\nReproduce steps:\n\n1. Create a cache device consisting of 1024 cache entries\n\ndmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\"\ndmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\"\ndmsetup create corig --table \"0 262144 linear /dev/sdc 262144\"\ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \"0 262144 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\"\n\n2. Populate the cache, and record the number of cached blocks\n\nfio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \\\n--size=64m --direct=1\nnr_cached=$(dmsetup status cache | awk \u0027{split($7, a, \"/\"); print a[1]}\u0027)\n\n3. Reload the cache into passthrough mode\n\ndmsetup suspend cache\ndmsetup reload cache --table \"0 262144 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0\"\ndmsetup resume cache\n\n4. Write to the passthrough cache. By setting multiple jobs with I/O\n size equal to the cache block size, cache blocks are invalidated\n concurrently from different workers.\n\nfio --filename=/dev/mapper/cache --name=test --rw=randwrite --bs=64k \\\n--direct=1 --numjobs=2 --randrepeat=0 --size=64m\n\n5. Check if demoted matches cached block count. These numbers should\n match but may differ due to the data race.\n\nnr_demoted=$(dmsetup status cache | awk \u0027{print $12}\u0027)\necho \"$nr_cached, $nr_demoted\"",
"id": "GHSA-4j2m-gfqm-629p",
"modified": "2026-06-28T09:31:40Z",
"published": "2026-06-24T18:32:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53062"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1b2bec4a7dcf5f00b7a1cbeeec8997841d783513"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b62d0611c9af14a16bddf22df2612b4f40eb5a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2d1f7b65f5deedd2e6b09fdc6ea27f8375f24b45"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4991b5a08751e2e82488fb93ae08849b6aea10d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93627a29d4b66d4a2def938dfb8610cc80ae454b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a5fdfb9e57ec3a8ad2b8fce5e5ffa42d53b130e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac5ee99443891bdb161f5539606a66a1b5e72542"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c348ae47d8e65f06429fa41adce9ad986b696766"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4JR3-HWQP-2VQ3
Vulnerability from github – Published: 2024-03-03 00:30 – Updated: 2024-12-11 18:30In the Linux kernel, the following vulnerability has been resolved:
dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock
__dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock.
Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we don't acquire serial console's port->lock under it.
Trimmed-down lockdep splat:
The existing dependency chain (in reverse order) is:
-> #2 (free_entries_lock){-.-.}-{2:2}:
_raw_spin_lock_irqsave+0x60/0x80
dma_entry_alloc+0x38/0x110
debug_dma_map_page+0x60/0xf8
dma_map_page_attrs+0x1e0/0x230
dma_map_single_attrs.constprop.0+0x6c/0xc8
geni_se_rx_dma_prep+0x40/0xcc
qcom_geni_serial_isr+0x310/0x510
__handle_irq_event_percpu+0x110/0x244
handle_irq_event_percpu+0x20/0x54
handle_irq_event+0x50/0x88
handle_fasteoi_irq+0xa4/0xcc
handle_irq_desc+0x28/0x40
generic_handle_domain_irq+0x24/0x30
gic_handle_irq+0xc4/0x148
do_interrupt_handler+0xa4/0xb0
el1_interrupt+0x34/0x64
el1h_64_irq_handler+0x18/0x24
el1h_64_irq+0x64/0x68
arch_local_irq_enable+0x4/0x8
____do_softirq+0x18/0x24
...
-> #1 (&port_lock_key){-.-.}-{2:2}:
_raw_spin_lock_irqsave+0x60/0x80
qcom_geni_serial_console_write+0x184/0x1dc
console_flush_all+0x344/0x454
console_unlock+0x94/0xf0
vprintk_emit+0x238/0x24c
vprintk_default+0x3c/0x48
vprintk+0xb4/0xbc
_printk+0x68/0x90
register_console+0x230/0x38c
uart_add_one_port+0x338/0x494
qcom_geni_serial_probe+0x390/0x424
platform_probe+0x70/0xc0
really_probe+0x148/0x280
__driver_probe_device+0xfc/0x114
driver_probe_device+0x44/0x100
__device_attach_driver+0x64/0xdc
bus_for_each_drv+0xb0/0xd8
__device_attach+0xe4/0x140
device_initial_probe+0x1c/0x28
bus_probe_device+0x44/0xb0
device_add+0x538/0x668
of_device_add+0x44/0x50
of_platform_device_create_pdata+0x94/0xc8
of_platform_bus_create+0x270/0x304
of_platform_populate+0xac/0xc4
devm_of_platform_populate+0x60/0xac
geni_se_probe+0x154/0x160
platform_probe+0x70/0xc0
...
-> #0 (console_owner){-...}-{0:0}:
__lock_acquire+0xdf8/0x109c
lock_acquire+0x234/0x284
console_flush_all+0x330/0x454
console_unlock+0x94/0xf0
vprintk_emit+0x238/0x24c
vprintk_default+0x3c/0x48
vprintk+0xb4/0xbc
_printk+0x68/0x90
dma_entry_alloc+0xb4/0x110
debug_dma_map_sg+0xdc/0x2f8
__dma_map_sg_attrs+0xac/0xe4
dma_map_sgtable+0x30/0x4c
get_pages+0x1d4/0x1e4 [msm]
msm_gem_pin_pages_locked+0x38/0xac [msm]
msm_gem_pin_vma_locked+0x58/0x88 [msm]
msm_ioctl_gem_submit+0xde4/0x13ac [msm]
drm_ioctl_kernel+0xe0/0x15c
drm_ioctl+0x2e8/0x3f4
vfs_ioctl+0x30/0x50
...
Chain exists of: console_owner --> &port_lock_key --> free_entries_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(free_entries_lock); lock(&port_lock_key); lock(free_entries_lock); lock(console_owner);
*** DEADLOCK ***
Call trace: dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-52516"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-02T22:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndma-debug: don\u0027t call __dma_entry_alloc_check_leak() under free_entries_lock\n\n__dma_entry_alloc_check_leak() calls into printk -\u003e serial console\noutput (qcom geni) and grabs port-\u003elock under free_entries_lock\nspin lock, which is a reverse locking dependency chain as qcom_geni\nIRQ handler can call into dma-debug code and grab free_entries_lock\nunder port-\u003elock.\n\nMove __dma_entry_alloc_check_leak() call out of free_entries_lock\nscope so that we don\u0027t acquire serial console\u0027s port-\u003elock under it.\n\nTrimmed-down lockdep splat:\n\n The existing dependency chain (in reverse order) is:\n\n -\u003e #2 (free_entries_lock){-.-.}-{2:2}:\n _raw_spin_lock_irqsave+0x60/0x80\n dma_entry_alloc+0x38/0x110\n debug_dma_map_page+0x60/0xf8\n dma_map_page_attrs+0x1e0/0x230\n dma_map_single_attrs.constprop.0+0x6c/0xc8\n geni_se_rx_dma_prep+0x40/0xcc\n qcom_geni_serial_isr+0x310/0x510\n __handle_irq_event_percpu+0x110/0x244\n handle_irq_event_percpu+0x20/0x54\n handle_irq_event+0x50/0x88\n handle_fasteoi_irq+0xa4/0xcc\n handle_irq_desc+0x28/0x40\n generic_handle_domain_irq+0x24/0x30\n gic_handle_irq+0xc4/0x148\n do_interrupt_handler+0xa4/0xb0\n el1_interrupt+0x34/0x64\n el1h_64_irq_handler+0x18/0x24\n el1h_64_irq+0x64/0x68\n arch_local_irq_enable+0x4/0x8\n ____do_softirq+0x18/0x24\n ...\n\n -\u003e #1 (\u0026port_lock_key){-.-.}-{2:2}:\n _raw_spin_lock_irqsave+0x60/0x80\n qcom_geni_serial_console_write+0x184/0x1dc\n console_flush_all+0x344/0x454\n console_unlock+0x94/0xf0\n vprintk_emit+0x238/0x24c\n vprintk_default+0x3c/0x48\n vprintk+0xb4/0xbc\n _printk+0x68/0x90\n register_console+0x230/0x38c\n uart_add_one_port+0x338/0x494\n qcom_geni_serial_probe+0x390/0x424\n platform_probe+0x70/0xc0\n really_probe+0x148/0x280\n __driver_probe_device+0xfc/0x114\n driver_probe_device+0x44/0x100\n __device_attach_driver+0x64/0xdc\n bus_for_each_drv+0xb0/0xd8\n __device_attach+0xe4/0x140\n device_initial_probe+0x1c/0x28\n bus_probe_device+0x44/0xb0\n device_add+0x538/0x668\n of_device_add+0x44/0x50\n of_platform_device_create_pdata+0x94/0xc8\n of_platform_bus_create+0x270/0x304\n of_platform_populate+0xac/0xc4\n devm_of_platform_populate+0x60/0xac\n geni_se_probe+0x154/0x160\n platform_probe+0x70/0xc0\n ...\n\n -\u003e #0 (console_owner){-...}-{0:0}:\n __lock_acquire+0xdf8/0x109c\n lock_acquire+0x234/0x284\n console_flush_all+0x330/0x454\n console_unlock+0x94/0xf0\n vprintk_emit+0x238/0x24c\n vprintk_default+0x3c/0x48\n vprintk+0xb4/0xbc\n _printk+0x68/0x90\n dma_entry_alloc+0xb4/0x110\n debug_dma_map_sg+0xdc/0x2f8\n __dma_map_sg_attrs+0xac/0xe4\n dma_map_sgtable+0x30/0x4c\n get_pages+0x1d4/0x1e4 [msm]\n msm_gem_pin_pages_locked+0x38/0xac [msm]\n msm_gem_pin_vma_locked+0x58/0x88 [msm]\n msm_ioctl_gem_submit+0xde4/0x13ac [msm]\n drm_ioctl_kernel+0xe0/0x15c\n drm_ioctl+0x2e8/0x3f4\n vfs_ioctl+0x30/0x50\n ...\n\n Chain exists of:\n console_owner --\u003e \u0026port_lock_key --\u003e free_entries_lock\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(free_entries_lock);\n lock(\u0026port_lock_key);\n lock(free_entries_lock);\n lock(console_owner);\n\n *** DEADLOCK ***\n\n Call trace:\n dump_backtrace+0xb4/0xf0\n show_stack+0x20/0x30\n dump_stack_lvl+0x60/0x84\n dump_stack+0x18/0x24\n print_circular_bug+0x1cc/0x234\n check_noncircular+0x78/0xac\n __lock_acquire+0xdf8/0x109c\n lock_acquire+0x234/0x284\n console_flush_all+0x330/0x454\n consol\n---truncated---",
"id": "GHSA-4jr3-hwqp-2vq3",
"modified": "2024-12-11T18:30:36Z",
"published": "2024-03-03T00:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52516"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac0d068099349cbca3d93f2e3b15bb329364b08c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be8f49029eca3efbad0d74dbff3cb9129994ffab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c79300599923daaa30f417c75555d5566b3d31ae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fb5a4315591dae307a65fc246ca80b5159d296e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe2b811a02c3244ebf6059039e4a9e715e26a9e3"
}
],
"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"
}
]
}
GHSA-4Q76-CFMR-JQCP
Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2022-05-24 16:58An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges by leveraging incorrect use of the HVM physmap concept for PV domains.
{
"affected": [],
"aliases": [
"CVE-2019-17343"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-08T01:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges by leveraging incorrect use of the HVM physmap concept for PV domains.",
"id": "GHSA-4q76-cfmr-jqcp",
"modified": "2022-05-24T16:58:09Z",
"published": "2022-05-24T16:58:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17343"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2020/Jan/21"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4602"
},
{
"type": "WEB",
"url": "https://xenbits.xen.org/xsa/advisory-288.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/10/25/10"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-288.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4QCC-96J2-GV42
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2025-02-03 18:30In the Linux kernel, the following vulnerability has been resolved:
ice: fix LAG and VF lock dependency in ice_reset_vf()
9f74a3dfcf83 ("ice: Fix VF Reset paths when interface in a failed over aggregate"), the ice driver has acquired the LAG mutex in ice_reset_vf(). The commit placed this lock acquisition just prior to the acquisition of the VF configuration lock.
If ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK flag, this could deadlock with ice_vc_cfg_qs_msg() because it always acquires the locks in the order of the VF configuration lock and then the LAG mutex.
Lockdep reports this violation almost immediately on creating and then removing 2 VF:
====================================================== WARNING: possible circular locking dependency detected 6.8.0-rc6 #54 Tainted: G W O
kworker/60:3/6771 is trying to acquire lock: ff40d43e099380a0 (&vf->cfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice]
but task is already holding lock: ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&pf->lag_mutex){+.+.}-{3:3}: __lock_acquire+0x4f8/0xb40 lock_acquire+0xd4/0x2d0 __mutex_lock+0x9b/0xbf0 ice_vc_cfg_qs_msg+0x45/0x690 [ice] ice_vc_process_vf_msg+0x4f5/0x870 [ice] __ice_clean_ctrlq+0x2b5/0x600 [ice] ice_service_task+0x2c9/0x480 [ice] process_one_work+0x1e9/0x4d0 worker_thread+0x1e1/0x3d0 kthread+0x104/0x140 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1b/0x30
-> #0 (&vf->cfg_lock){+.+.}-{3:3}: check_prev_add+0xe2/0xc50 validate_chain+0x558/0x800 __lock_acquire+0x4f8/0xb40 lock_acquire+0xd4/0x2d0 __mutex_lock+0x9b/0xbf0 ice_reset_vf+0x22f/0x4d0 [ice] ice_process_vflr_event+0x98/0xd0 [ice] ice_service_task+0x1cc/0x480 [ice] process_one_work+0x1e9/0x4d0 worker_thread+0x1e1/0x3d0 kthread+0x104/0x140 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1b/0x30
other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&pf->lag_mutex); lock(&vf->cfg_lock); lock(&pf->lag_mutex); lock(&vf->cfg_lock);
*** DEADLOCK *** 4 locks held by kworker/60:3/6771: #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0 #1: ff50d06e05197e58 ((work_completion)(&pf->serv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0 #2: ff40d43ea1960e50 (&pf->vfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice] #3: ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]
stack backtrace: CPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G W O 6.8.0-rc6 #54 Hardware name: Workqueue: ice ice_service_task [ice] Call Trace: dump_stack_lvl+0x4a/0x80 check_noncircular+0x12d/0x150 check_prev_add+0xe2/0xc50 ? save_trace+0x59/0x230 ? add_chain_cache+0x109/0x450 validate_chain+0x558/0x800 __lock_acquire+0x4f8/0xb40 ? lockdep_hardirqs_on+0x7d/0x100 lock_acquire+0xd4/0x2d0 ? ice_reset_vf+0x22f/0x4d0 [ice] ? lock_is_held_type+0xc7/0x120 __mutex_lock+0x9b/0xbf0 ? ice_reset_vf+0x22f/0x4d0 [ice] ? ice_reset_vf+0x22f/0x4d0 [ice] ? rcu_is_watching+0x11/0x50 ? ice_reset_vf+0x22f/0x4d0 [ice] ice_reset_vf+0x22f/0x4d0 [ice] ? process_one_work+0x176/0x4d0 ice_process_vflr_event+0x98/0xd0 [ice] ice_service_task+0x1cc/0x480 [ice] process_one_work+0x1e9/0x4d0 worker_thread+0x1e1/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x104/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30
To avoid deadlock, we must acquire the LAG ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-36003"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix LAG and VF lock dependency in ice_reset_vf()\n\n9f74a3dfcf83 (\"ice: Fix VF Reset paths when interface in a failed over\naggregate\"), the ice driver has acquired the LAG mutex in ice_reset_vf().\nThe commit placed this lock acquisition just prior to the acquisition of\nthe VF configuration lock.\n\nIf ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK\nflag, this could deadlock with ice_vc_cfg_qs_msg() because it always\nacquires the locks in the order of the VF configuration lock and then the\nLAG mutex.\n\nLockdep reports this violation almost immediately on creating and then\nremoving 2 VF:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.8.0-rc6 #54 Tainted: G W O\n------------------------------------------------------\nkworker/60:3/6771 is trying to acquire lock:\nff40d43e099380a0 (\u0026vf-\u003ecfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice]\n\nbut task is already holding lock:\nff40d43ea1961210 (\u0026pf-\u003elag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #1 (\u0026pf-\u003elag_mutex){+.+.}-{3:3}:\n __lock_acquire+0x4f8/0xb40\n lock_acquire+0xd4/0x2d0\n __mutex_lock+0x9b/0xbf0\n ice_vc_cfg_qs_msg+0x45/0x690 [ice]\n ice_vc_process_vf_msg+0x4f5/0x870 [ice]\n __ice_clean_ctrlq+0x2b5/0x600 [ice]\n ice_service_task+0x2c9/0x480 [ice]\n process_one_work+0x1e9/0x4d0\n worker_thread+0x1e1/0x3d0\n kthread+0x104/0x140\n ret_from_fork+0x31/0x50\n ret_from_fork_asm+0x1b/0x30\n\n-\u003e #0 (\u0026vf-\u003ecfg_lock){+.+.}-{3:3}:\n check_prev_add+0xe2/0xc50\n validate_chain+0x558/0x800\n __lock_acquire+0x4f8/0xb40\n lock_acquire+0xd4/0x2d0\n __mutex_lock+0x9b/0xbf0\n ice_reset_vf+0x22f/0x4d0 [ice]\n ice_process_vflr_event+0x98/0xd0 [ice]\n ice_service_task+0x1cc/0x480 [ice]\n process_one_work+0x1e9/0x4d0\n worker_thread+0x1e1/0x3d0\n kthread+0x104/0x140\n ret_from_fork+0x31/0x50\n ret_from_fork_asm+0x1b/0x30\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n CPU0 CPU1\n ---- ----\n lock(\u0026pf-\u003elag_mutex);\n lock(\u0026vf-\u003ecfg_lock);\n lock(\u0026pf-\u003elag_mutex);\n lock(\u0026vf-\u003ecfg_lock);\n\n *** DEADLOCK ***\n4 locks held by kworker/60:3/6771:\n #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0\n #1: ff50d06e05197e58 ((work_completion)(\u0026pf-\u003eserv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0\n #2: ff40d43ea1960e50 (\u0026pf-\u003evfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice]\n #3: ff40d43ea1961210 (\u0026pf-\u003elag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]\n\nstack backtrace:\nCPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G W O 6.8.0-rc6 #54\nHardware name:\nWorkqueue: ice ice_service_task [ice]\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x4a/0x80\n check_noncircular+0x12d/0x150\n check_prev_add+0xe2/0xc50\n ? save_trace+0x59/0x230\n ? add_chain_cache+0x109/0x450\n validate_chain+0x558/0x800\n __lock_acquire+0x4f8/0xb40\n ? lockdep_hardirqs_on+0x7d/0x100\n lock_acquire+0xd4/0x2d0\n ? ice_reset_vf+0x22f/0x4d0 [ice]\n ? lock_is_held_type+0xc7/0x120\n __mutex_lock+0x9b/0xbf0\n ? ice_reset_vf+0x22f/0x4d0 [ice]\n ? ice_reset_vf+0x22f/0x4d0 [ice]\n ? rcu_is_watching+0x11/0x50\n ? ice_reset_vf+0x22f/0x4d0 [ice]\n ice_reset_vf+0x22f/0x4d0 [ice]\n ? process_one_work+0x176/0x4d0\n ice_process_vflr_event+0x98/0xd0 [ice]\n ice_service_task+0x1cc/0x480 [ice]\n process_one_work+0x1e9/0x4d0\n worker_thread+0x1e1/0x3d0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x104/0x140\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u003c/TASK\u003e\n\nTo avoid deadlock, we must acquire the LAG \n---truncated---",
"id": "GHSA-4qcc-96j2-gv42",
"modified": "2025-02-03T18:30:37Z",
"published": "2024-05-20T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36003"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6"
}
],
"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"
}
]
}
Mitigation
Strategy: Libraries or Frameworks
Use industry standard APIs to implement locking mechanism.
CAPEC-25: Forced Deadlock
The adversary triggers and exploits a deadlock condition in the target software to cause a denial of service. A deadlock can occur when two or more competing actions are waiting for each other to finish, and thus neither ever does. Deadlock conditions can be difficult to detect.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.
CAPEC-27: Leveraging Race Conditions via Symbolic Links
This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.