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.
713 vulnerabilities reference this CWE, most recent first.
GHSA-VHCC-WFM4-93WW
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-21 18:30In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync
roc_abort_sync() can deadlock with roc_work(). roc_work() holds dev->mt76.mutex, while cancel_work_sync() waits for roc_work() to finish. If the caller already owns the same mutex, both sides block and no progress is possible.
This deadlock can occur during station removal when mt76_sta_state() -> mt76_sta_remove() -> mt7921_mac_sta_remove() -> mt7921_roc_abort_sync() invokes cancel_work_sync() while roc_work() is still running and holding dev->mt76.mutex.
This avoids the mutex deadlock and preserves exactly-once work ownership.
{
"affected": [],
"aliases": [
"CVE-2026-53101"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync\n\nroc_abort_sync() can deadlock with roc_work(). roc_work() holds\ndev-\u003emt76.mutex, while cancel_work_sync() waits for roc_work()\nto finish. If the caller already owns the same mutex, both\nsides block and no progress is possible.\n\nThis deadlock can occur during station removal when\nmt76_sta_state() -\u003e mt76_sta_remove() -\u003e mt7921_mac_sta_remove() -\u003e\nmt7921_roc_abort_sync() invokes cancel_work_sync() while\nroc_work() is still running and holding dev-\u003emt76.mutex.\n\nThis avoids the mutex deadlock and preserves exactly-once\nwork ownership.",
"id": "GHSA-vhcc-wfm4-93ww",
"modified": "2026-07-21T18:30:43Z",
"published": "2026-06-24T18:32:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53101"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35180c772f5e11e2fa4d80d3dfd50906cb6d9646"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/91e77840bf13de3add125060cf8b32ca24a52c8c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4faaa617af3f4173e64169b0ec1af8f9c5bca10"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5059e52fd8bc624ec4255c9fa01a266513d126b"
}
],
"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-VJ32-JVRG-MHMW
Vulnerability from github – Published: 2023-12-05 18:30 – Updated: 2023-12-05 18:30Dell PowerEdge platforms 16G Intel E5 BIOS and Dell Precision BIOS, version 1.4.4, contain active debug code security vulnerability. An unauthenticated physical attacker could potentially exploit this vulnerability, leading to information tampering, code execution, denial of service.
{
"affected": [],
"aliases": [
"CVE-2023-44298"
],
"database_specific": {
"cwe_ids": [
"CWE-1234",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-05T16:15:07Z",
"severity": "LOW"
},
"details": "\nDell PowerEdge platforms 16G Intel E5 BIOS and Dell Precision BIOS, version 1.4.4, contain active debug code security vulnerability. An unauthenticated physical attacker could potentially exploit this vulnerability, leading to information tampering, code execution, denial of service.\n\n",
"id": "GHSA-vj32-jvrg-mhmw",
"modified": "2023-12-05T18:30:23Z",
"published": "2023-12-05T18:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44298"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000220047/dsa-2023-429-security-update-for-dell-16g-poweredge-server-bios-for-a-debug-code-security-vulnerability"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-VJMW-VHP2-PCR2
Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-12-02 21:31In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8723bs: Fix locking in _rtw_join_timeout_handler()
Commit 041879b12ddb ("drivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle()") besides fixing the deadlock also modified rtw_join_timeout_handler() to use spin[un]lock_irq() instead of spin_[un]lock_bh().
rtw_join_timeout_handler() calls rtw_do_join() which takes pmlmepriv->scanned_queue.lock using spin[un]lock_bh(). This spin_unlock_bh() call re-enables softirqs which triggers an oops in kernel/softirq.c: __local_bh_enable_ip() when it calls lockdep_assert_irqs_enabled():
[ 244.506087] WARNING: CPU: 2 PID: 0 at kernel/softirq.c:376 __local_bh_enable_ip+0xa6/0x100 ... [ 244.509022] Call Trace: [ 244.509048] [ 244.509100] _rtw_join_timeout_handler+0x134/0x170 [r8723bs] [ 244.509468] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs] [ 244.509772] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs] [ 244.510076] call_timer_fn+0x95/0x2a0 [ 244.510200] __run_timers.part.0+0x1da/0x2d0
This oops is causd by the switch to spin_[un]lock_irq() which disables the IRQs for the entire duration of _rtw_join_timeout_handler().
Disabling the IRQs is not necessary since all code taking this lock runs from either user contexts or from softirqs, switch back to spin_[un]lock_bh() to fix this.
{
"affected": [],
"aliases": [
"CVE-2023-53281"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T08:15:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: staging: rtl8723bs: Fix locking in _rtw_join_timeout_handler()\n\nCommit 041879b12ddb (\"drivers: staging: rtl8192bs: Fix deadlock in\nrtw_joinbss_event_prehandle()\") besides fixing the deadlock also\nmodified _rtw_join_timeout_handler() to use spin_[un]lock_irq()\ninstead of spin_[un]lock_bh().\n\n_rtw_join_timeout_handler() calls rtw_do_join() which takes\npmlmepriv-\u003escanned_queue.lock using spin_[un]lock_bh(). This\nspin_unlock_bh() call re-enables softirqs which triggers an oops in\nkernel/softirq.c: __local_bh_enable_ip() when it calls\nlockdep_assert_irqs_enabled():\n\n[ 244.506087] WARNING: CPU: 2 PID: 0 at kernel/softirq.c:376 __local_bh_enable_ip+0xa6/0x100\n...\n[ 244.509022] Call Trace:\n[ 244.509048] \u003cIRQ\u003e\n[ 244.509100] _rtw_join_timeout_handler+0x134/0x170 [r8723bs]\n[ 244.509468] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs]\n[ 244.509772] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs]\n[ 244.510076] call_timer_fn+0x95/0x2a0\n[ 244.510200] __run_timers.part.0+0x1da/0x2d0\n\nThis oops is causd by the switch to spin_[un]lock_irq() which disables\nthe IRQs for the entire duration of _rtw_join_timeout_handler().\n\nDisabling the IRQs is not necessary since all code taking this lock\nruns from either user contexts or from softirqs, switch back to\nspin_[un]lock_bh() to fix this.",
"id": "GHSA-vjmw-vhp2-pcr2",
"modified": "2025-12-02T21:31:26Z",
"published": "2025-09-16T15:32:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53281"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/209850f17717a3b5cc558578bef5631ac7045539"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/215792eda008f6a1e7ed9d77fa20d582d22bb114"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a50e44a66d268ee5db3d177f1fdc1503dbce6e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ab1bace1dd3875371b481ef4301c4671bddea22"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dc327e87c6d9bfd9ee08e76396b3c0ba848ec554"
}
],
"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-VMVH-GJ86-W48F
Vulnerability from github – Published: 2025-09-17 15:30 – Updated: 2025-12-11 15:30In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock when aborting transaction during relocation with scrub
Before relocating a block group we pause scrub, then do the relocation and then unpause scrub. The relocation process requires starting and committing a transaction, and if we have a failure in the critical section of the transaction commit path (transaction state >= TRANS_STATE_COMMIT_START), we will deadlock if there is a paused scrub.
That results in stack traces like the following:
[42.479] BTRFS info (device sdc): relocating block group 53876686848 flags metadata|raid6 [42.936] BTRFS warning (device sdc): Skipping commit of aborted transaction. [42.936] ------------[ cut here ]------------ [42.936] BTRFS: Transaction aborted (error -28) [42.936] WARNING: CPU: 11 PID: 346822 at fs/btrfs/transaction.c:1977 btrfs_commit_transaction+0xcc8/0xeb0 [btrfs] [42.936] Modules linked in: dm_flakey dm_mod loop btrfs (...) [42.936] CPU: 11 PID: 346822 Comm: btrfs Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1 [42.936] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [42.936] RIP: 0010:btrfs_commit_transaction+0xcc8/0xeb0 [btrfs] [42.936] Code: ff ff 45 8b (...) [42.936] RSP: 0018:ffffb58649633b48 EFLAGS: 00010282 [42.936] RAX: 0000000000000000 RBX: ffff8be6ef4d5bd8 RCX: 0000000000000000 [42.936] RDX: 0000000000000002 RSI: ffffffffb35e7782 RDI: 00000000ffffffff [42.936] RBP: ffff8be6ef4d5c98 R08: 0000000000000000 R09: ffffb586496339e8 [42.936] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8be6d38c7c00 [42.936] R13: 00000000ffffffe4 R14: ffff8be6c268c000 R15: ffff8be6ef4d5cf0 [42.936] FS: 00007f381a82b340(0000) GS:ffff8beddfcc0000(0000) knlGS:0000000000000000 [42.936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42.936] CR2: 00007f1e35fb7638 CR3: 0000000117680006 CR4: 0000000000370ee0 [42.936] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42.936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42.936] Call Trace: [42.936] [42.936] ? start_transaction+0xcb/0x610 [btrfs] [42.936] prepare_to_relocate+0x111/0x1a0 [btrfs] [42.936] relocate_block_group+0x57/0x5d0 [btrfs] [42.936] ? btrfs_wait_nocow_writers+0x25/0xb0 [btrfs] [42.936] btrfs_relocate_block_group+0x248/0x3c0 [btrfs] [42.936] ? __pfx_autoremove_wake_function+0x10/0x10 [42.936] btrfs_relocate_chunk+0x3b/0x150 [btrfs] [42.936] btrfs_balance+0x8ff/0x11d0 [btrfs] [42.936] ? __kmem_cache_alloc_node+0x14a/0x410 [42.936] btrfs_ioctl+0x2334/0x32c0 [btrfs] [42.937] ? mod_objcg_state+0xd2/0x360 [42.937] ? refill_obj_stock+0xb0/0x160 [42.937] ? seq_release+0x25/0x30 [42.937] ? __rseq_handle_notify_resume+0x3b5/0x4b0 [42.937] ? percpu_counter_add_batch+0x2e/0xa0 [42.937] ? __x64_sys_ioctl+0x88/0xc0 [42.937] __x64_sys_ioctl+0x88/0xc0 [42.937] do_syscall_64+0x38/0x90 [42.937] entry_SYSCALL_64_after_hwframe+0x72/0xdc [42.937] RIP: 0033:0x7f381a6ffe9b [42.937] Code: 00 48 89 44 24 (...) [42.937] RSP: 002b:00007ffd45ecf060 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [42.937] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f381a6ffe9b [42.937] RDX: 00007ffd45ecf150 RSI: 00000000c4009420 RDI: 0000000000000003 [42.937] RBP: 0000000000000003 R08: 0000000000000013 R09: 0000000000000000 [42.937] R10: 00007f381a60c878 R11: 0000000000000246 R12: 00007ffd45ed0423 [42.937] R13: 00007ffd45ecf150 R14: 0000000000000000 R15: 00007ffd45ecf148 [42.937] [42.937] ---[ end trace 0000000000000000 ]--- [42.937] BTRFS: error (device sdc: state A) in cleanup_transaction:1977: errno=-28 No space left [59.196] INFO: task btrfs:346772 blocked for more than 120 seconds. [59.196] Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1 [59.196] "echo 0 > /proc/sys/kernel/hung_ ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-53348"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-17T15:15:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock when aborting transaction during relocation with scrub\n\nBefore relocating a block group we pause scrub, then do the relocation and\nthen unpause scrub. The relocation process requires starting and committing\na transaction, and if we have a failure in the critical section of the\ntransaction commit path (transaction state \u003e= TRANS_STATE_COMMIT_START),\nwe will deadlock if there is a paused scrub.\n\nThat results in stack traces like the following:\n\n [42.479] BTRFS info (device sdc): relocating block group 53876686848 flags metadata|raid6\n [42.936] BTRFS warning (device sdc): Skipping commit of aborted transaction.\n [42.936] ------------[ cut here ]------------\n [42.936] BTRFS: Transaction aborted (error -28)\n [42.936] WARNING: CPU: 11 PID: 346822 at fs/btrfs/transaction.c:1977 btrfs_commit_transaction+0xcc8/0xeb0 [btrfs]\n [42.936] Modules linked in: dm_flakey dm_mod loop btrfs (...)\n [42.936] CPU: 11 PID: 346822 Comm: btrfs Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1\n [42.936] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n [42.936] RIP: 0010:btrfs_commit_transaction+0xcc8/0xeb0 [btrfs]\n [42.936] Code: ff ff 45 8b (...)\n [42.936] RSP: 0018:ffffb58649633b48 EFLAGS: 00010282\n [42.936] RAX: 0000000000000000 RBX: ffff8be6ef4d5bd8 RCX: 0000000000000000\n [42.936] RDX: 0000000000000002 RSI: ffffffffb35e7782 RDI: 00000000ffffffff\n [42.936] RBP: ffff8be6ef4d5c98 R08: 0000000000000000 R09: ffffb586496339e8\n [42.936] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8be6d38c7c00\n [42.936] R13: 00000000ffffffe4 R14: ffff8be6c268c000 R15: ffff8be6ef4d5cf0\n [42.936] FS: 00007f381a82b340(0000) GS:ffff8beddfcc0000(0000) knlGS:0000000000000000\n [42.936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [42.936] CR2: 00007f1e35fb7638 CR3: 0000000117680006 CR4: 0000000000370ee0\n [42.936] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n [42.936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n [42.936] Call Trace:\n [42.936] \u003cTASK\u003e\n [42.936] ? start_transaction+0xcb/0x610 [btrfs]\n [42.936] prepare_to_relocate+0x111/0x1a0 [btrfs]\n [42.936] relocate_block_group+0x57/0x5d0 [btrfs]\n [42.936] ? btrfs_wait_nocow_writers+0x25/0xb0 [btrfs]\n [42.936] btrfs_relocate_block_group+0x248/0x3c0 [btrfs]\n [42.936] ? __pfx_autoremove_wake_function+0x10/0x10\n [42.936] btrfs_relocate_chunk+0x3b/0x150 [btrfs]\n [42.936] btrfs_balance+0x8ff/0x11d0 [btrfs]\n [42.936] ? __kmem_cache_alloc_node+0x14a/0x410\n [42.936] btrfs_ioctl+0x2334/0x32c0 [btrfs]\n [42.937] ? mod_objcg_state+0xd2/0x360\n [42.937] ? refill_obj_stock+0xb0/0x160\n [42.937] ? seq_release+0x25/0x30\n [42.937] ? __rseq_handle_notify_resume+0x3b5/0x4b0\n [42.937] ? percpu_counter_add_batch+0x2e/0xa0\n [42.937] ? __x64_sys_ioctl+0x88/0xc0\n [42.937] __x64_sys_ioctl+0x88/0xc0\n [42.937] do_syscall_64+0x38/0x90\n [42.937] entry_SYSCALL_64_after_hwframe+0x72/0xdc\n [42.937] RIP: 0033:0x7f381a6ffe9b\n [42.937] Code: 00 48 89 44 24 (...)\n [42.937] RSP: 002b:00007ffd45ecf060 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n [42.937] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f381a6ffe9b\n [42.937] RDX: 00007ffd45ecf150 RSI: 00000000c4009420 RDI: 0000000000000003\n [42.937] RBP: 0000000000000003 R08: 0000000000000013 R09: 0000000000000000\n [42.937] R10: 00007f381a60c878 R11: 0000000000000246 R12: 00007ffd45ed0423\n [42.937] R13: 00007ffd45ecf150 R14: 0000000000000000 R15: 00007ffd45ecf148\n [42.937] \u003c/TASK\u003e\n [42.937] ---[ end trace 0000000000000000 ]---\n [42.937] BTRFS: error (device sdc: state A) in cleanup_transaction:1977: errno=-28 No space left\n [59.196] INFO: task btrfs:346772 blocked for more than 120 seconds.\n [59.196] Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1\n [59.196] \"echo 0 \u003e /proc/sys/kernel/hung_\n---truncated---",
"id": "GHSA-vmvh-gj86-w48f",
"modified": "2025-12-11T15:30:29Z",
"published": "2025-09-17T15:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53348"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10a5831b193390b77705fc174a309476c23ba64a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2d82a40aa7d6fcae0250ec68b8566cdee7bfd44c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6134a4bb6b1c411a244edee041ac89266c78d45c"
}
],
"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-VMW4-6X55-PGFQ
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-09 21:32In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang()
The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and readl(crtc_reg) will access with random address, because the "device" is from "base+PCI_DEVICE_ID", "base" is from "pdev->devfn+1". This is wrong when my platform inserts a discrete GPU:
lspci -tv -[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller ... +-06.0 Loongson Technology LLC LG100 GPU +-06.2 Loongson Technology LLC Device 7a37 ...
Add a default switch case to fix the panic as below:
Kernel ade access[#1]: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4 pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0 a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002 a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001 t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000 t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0 t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8 s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000 s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000 ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210 ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1) BADV: 7fffffffffffff00 PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(_ptrval), task=(_ptrval)) Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007 0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff 900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08 0000000000000000 0000000000000000 0000000000000006 90000001002fb778 90000001000530b8 90000000027af000 0000000000000000 9000000100054000 9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001 90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000 0000000000000006 90000000027af000 0000000000000030 90000000027af000 900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560 7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030 ... Call Trace: [<90000000017e5534>] loongson_gpu_fixup_dma_hang+0xb4/0x210 [<9000000000eebc08>] pci_fixup_device+0x108/0x280 [<9000000000ebb70c>] pci_setup_device+0x24c/0x690 [<9000000000ebc560>] pci_scan_single_device+0xe0/0x140 [<9000000000ebc684>] pci_scan_slot+0xc4/0x280 [<9000000000ebdd00>] pci_scan_child_bus_extend+0x60/0x3f0 [<9000000000f5bc94>] acpi_pci_root_create+0x2b4/0x420 [<90000000017e5e74>] pci_acpi_scan_root+0x2d4/0x440 [<9000000000f5b02c>] acpi_pci_root_add+0x21c/0x3a0 [<9000000000f4ee54>] acpi_bus_attach+0x1a4/0x3c0 [<90000000010e200c>] device_for_each_child+0x6c/0xe0 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0 [<90000000010e200c>] device_for_each_child+0x6c/0xe0 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0 [<9000000000f5211c>] acpi_bus_scan+0x6c/0x280 [<900000000189c028>] acpi_scan_init+0x194/0x310 [<900000000189bc6c>] acpi_init+0xcc/0x140 [<9000000000220cdc>] do_one_initcall+0x4c/0x310 [<90000000018618fc>] kernel_init_freeable+0x258/0x2d4 [<900000000184326c>] kernel_init+0x28/0x13c [<9000000000222008>] ret_from_kernel_thread+0xc/0xa4
{
"affected": [],
"aliases": [
"CVE-2026-46156"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang()\n\nThe switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and\nreadl(crtc_reg) will access with random address, because the \"device\" is\nfrom \"base+PCI_DEVICE_ID\", \"base\" is from \"pdev-\u003edevfn+1\". This is wrong\nwhen my platform inserts a discrete GPU:\n\nlspci -tv\n-[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller\n...\n +-06.0 Loongson Technology LLC LG100 GPU\n +-06.2 Loongson Technology LLC Device 7a37\n...\n\nAdd a default switch case to fix the panic as below:\n\n Kernel ade access[#1]:\n CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4\n pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0\n a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002\n a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001\n t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000\n t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0\n t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8\n s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000\n s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000\n ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210\n ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210\n CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)\n PRMD: 00000004 (PPLV0 +PIE -PWE)\n EUEN: 00000000 (-FPE -SXE -ASXE -BTE)\n ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)\n ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1)\n BADV: 7fffffffffffff00\n PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV)\n Modules linked in:\n Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____))\n Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007\n 0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff\n 900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08\n 0000000000000000 0000000000000000 0000000000000006 90000001002fb778\n 90000001000530b8 90000000027af000 0000000000000000 9000000100054000\n 9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001\n 90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000\n 0000000000000006 90000000027af000 0000000000000030 90000000027af000\n 900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560\n 7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030\n ...\n Call Trace:\n [\u003c90000000017e5534\u003e] loongson_gpu_fixup_dma_hang+0xb4/0x210\n [\u003c9000000000eebc08\u003e] pci_fixup_device+0x108/0x280\n [\u003c9000000000ebb70c\u003e] pci_setup_device+0x24c/0x690\n [\u003c9000000000ebc560\u003e] pci_scan_single_device+0xe0/0x140\n [\u003c9000000000ebc684\u003e] pci_scan_slot+0xc4/0x280\n [\u003c9000000000ebdd00\u003e] pci_scan_child_bus_extend+0x60/0x3f0\n [\u003c9000000000f5bc94\u003e] acpi_pci_root_create+0x2b4/0x420\n [\u003c90000000017e5e74\u003e] pci_acpi_scan_root+0x2d4/0x440\n [\u003c9000000000f5b02c\u003e] acpi_pci_root_add+0x21c/0x3a0\n [\u003c9000000000f4ee54\u003e] acpi_bus_attach+0x1a4/0x3c0\n [\u003c90000000010e200c\u003e] device_for_each_child+0x6c/0xe0\n [\u003c9000000000f4bbf4\u003e] acpi_dev_for_each_child+0x44/0x70\n [\u003c9000000000f4ef40\u003e] acpi_bus_attach+0x290/0x3c0\n [\u003c90000000010e200c\u003e] device_for_each_child+0x6c/0xe0\n [\u003c9000000000f4bbf4\u003e] acpi_dev_for_each_child+0x44/0x70\n [\u003c9000000000f4ef40\u003e] acpi_bus_attach+0x290/0x3c0\n [\u003c9000000000f5211c\u003e] acpi_bus_scan+0x6c/0x280\n [\u003c900000000189c028\u003e] acpi_scan_init+0x194/0x310\n [\u003c900000000189bc6c\u003e] acpi_init+0xcc/0x140\n [\u003c9000000000220cdc\u003e] do_one_initcall+0x4c/0x310\n [\u003c90000000018618fc\u003e] kernel_init_freeable+0x258/0x2d4\n [\u003c900000000184326c\u003e] kernel_init+0x28/0x13c\n [\u003c9000000000222008\u003e] ret_from_kernel_thread+0xc/0xa4",
"id": "GHSA-vmw4-6x55-pgfq",
"modified": "2026-06-09T21:32:19Z",
"published": "2026-05-28T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46156"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/07d190e4ec689d6478f7f5e36099fb9bf457e7c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cb19b06c09983727573bbe7d7430cbad480a714"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/81fef1c278436e6bd68ee4ca05a0acb96e256561"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8dfa2f8780e486d05b9a0ffce70b8f5fbd62053e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e1aed63a5552958ef2a9bfd699a3f990e52a77f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfde8accc3e3260c0ecbb8cc34361739e1e16f31"
}
],
"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-VQ56-9RJP-57FC
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-28 15:30In the Linux kernel, the following vulnerability has been resolved:
spi: use generic driver_override infrastructure
When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.
Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.
Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
Also note that we do not enable the driver_override feature of struct bus_type, as SPI - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n".
{
"affected": [],
"aliases": [
"CVE-2026-31487"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:46Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus\u0027 match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1]\n\nAlso note that we do not enable the driver_override feature of struct\nbus_type, as SPI - in contrast to most other buses - passes \"\" to\nsysfs_emit() when the driver_override pointer is NULL. Thus, printing\n\"\\n\" instead of \"(null)\\n\".",
"id": "GHSA-vq56-9rjp-57fc",
"modified": "2026-04-28T15:30:47Z",
"published": "2026-04-22T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31487"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c73a58661a760373d08a6883af4f0bb5cc991a67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc34d77dd48708d810c12bfd6f5bf03304f6c824"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e0ae367a2de06c49aa1de6ec9b1ab6860bbb2cf0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eedf220442d13b6d97294e5b0ac8a2c38ee1a1a0"
}
],
"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-VQ68-HHVF-C7XP
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-12-23 21:30In the Linux kernel, the following vulnerability has been resolved:
clk: Get runtime PM before walking tree for clk_summary
Similar to the previous commit, we should make sure that all devices are runtime resumed before printing the clk_summary through debugfs. Failure to do so would result in a deadlock if the thread is resuming a device to print clk state and that device is also runtime resuming in another thread, e.g the screen is turning on and the display driver is starting up. We remove the calls to clk_pm_runtime_{get,put}() in this path because they're superfluous now that we know the devices are runtime resumed. This also squashes a bug where the return value of clk_pm_runtime_get() wasn't checked, leading to an RPM count underflow on error paths.
{
"affected": [],
"aliases": [
"CVE-2024-27003"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: Get runtime PM before walking tree for clk_summary\n\nSimilar to the previous commit, we should make sure that all devices are\nruntime resumed before printing the clk_summary through debugfs. Failure\nto do so would result in a deadlock if the thread is resuming a device\nto print clk state and that device is also runtime resuming in another\nthread, e.g the screen is turning on and the display driver is starting\nup. We remove the calls to clk_pm_runtime_{get,put}() in this path\nbecause they\u0027re superfluous now that we know the devices are runtime\nresumed. This also squashes a bug where the return value of\nclk_pm_runtime_get() wasn\u0027t checked, leading to an RPM count underflow\non error paths.",
"id": "GHSA-vq68-hhvf-c7xp",
"modified": "2024-12-23T21:30:50Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27003"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2c077fdfd09dffb31a890e5095c8ab205138a42e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83ada89e4a86e2b28ea2b5113c76d6dc7560a4d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d1e795f754db1ac3344528b7af0b17b8146f321"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b457105309d388e4081c716cf7b81d517ff74db4"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
}
],
"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-VQ8Q-45X3-7Q6V
Vulnerability from github – Published: 2023-06-06 15:30 – Updated: 2024-04-04 04:35In vcu, there is a possible out of bounds write due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519142; Issue ID: ALPS07560694.
{
"affected": [],
"aliases": [
"CVE-2023-20745"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-06T13:15:14Z",
"severity": "MODERATE"
},
"details": "In vcu, there is a possible out of bounds write due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519142; Issue ID: ALPS07560694.",
"id": "GHSA-vq8q-45x3-7q6v",
"modified": "2024-04-04T04:35:41Z",
"published": "2023-06-06T15:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20745"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/June-2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-VR7F-QWXP-XQRP
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-19 15:31In the Linux kernel, the following vulnerability has been resolved:
riscv:uprobe fix SR_SPIE set/clear handling
In riscv the process of uprobe going to clear spie before exec the origin insn,and set spie after that.But When access the page which origin insn has been placed a page fault may happen and irq was disabled in arch_uprobe_pre_xol function,It cause a WARN as follows. There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol. We can just remove it.
[ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488 [ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work [ 31.684929] preempt_count: 0, expected: 0 [ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G [ 31.686542] Hardware name: riscv-virtio,qemu (DT) [ 31.686797] Call Trace: [ 31.687053] [] dump_backtrace+0x30/0x38 [ 31.687699] [] show_stack+0x40/0x4c [ 31.688141] [] dump_stack_lvl+0x44/0x5c [ 31.688396] [] dump_stack+0x18/0x20 [ 31.688653] [] __might_resched+0x114/0x122 [ 31.688948] [] __might_sleep+0x50/0x7a [ 31.689435] [] down_read+0x30/0x130 [ 31.689728] [] do_page_fault+0x166/x446 [ 31.689997] [] ret_from_exception+0x0/0xc
{
"affected": [],
"aliases": [
"CVE-2022-50225"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv:uprobe fix SR_SPIE set/clear handling\n\nIn riscv the process of uprobe going to clear spie before exec\nthe origin insn,and set spie after that.But When access the page\nwhich origin insn has been placed a page fault may happen and\nirq was disabled in arch_uprobe_pre_xol function,It cause a WARN\nas follows.\nThere is no need to clear/set spie in arch_uprobe_pre/post/abort_xol.\nWe can just remove it.\n\n[ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488\n[ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work\n[ 31.684929] preempt_count: 0, expected: 0\n[ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G\n[ 31.686542] Hardware name: riscv-virtio,qemu (DT)\n[ 31.686797] Call Trace:\n[ 31.687053] [\u003cffffffff80006442\u003e] dump_backtrace+0x30/0x38\n[ 31.687699] [\u003cffffffff80812118\u003e] show_stack+0x40/0x4c\n[ 31.688141] [\u003cffffffff8081817a\u003e] dump_stack_lvl+0x44/0x5c\n[ 31.688396] [\u003cffffffff808181aa\u003e] dump_stack+0x18/0x20\n[ 31.688653] [\u003cffffffff8003e454\u003e] __might_resched+0x114/0x122\n[ 31.688948] [\u003cffffffff8003e4b2\u003e] __might_sleep+0x50/0x7a\n[ 31.689435] [\u003cffffffff80822676\u003e] down_read+0x30/0x130\n[ 31.689728] [\u003cffffffff8000b650\u003e] do_page_fault+0x166/x446\n[ 31.689997] [\u003cffffffff80003c0c\u003e] ret_from_exception+0x0/0xc",
"id": "GHSA-vr7f-qwxp-xqrp",
"modified": "2025-11-19T15:31:31Z",
"published": "2025-06-18T12:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50225"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3811d51778900064d27d8c9a98f73410fb3b471d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3dbe5829408bc1586f75b4667ef60e5aab0209c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/73fc099eaefd9a92c83b6c07dad066411fd5a192"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c71e000db8536d27ec410abb3e314896a78b4f19"
}
],
"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-VR8J-HGMM-JH9R
Vulnerability from github – Published: 2022-12-13 18:30 – Updated: 2024-10-02 18:03If an X.509 certificate contains a malformed policy constraint and policy processing is enabled, then a write lock will be taken twice recursively. On some operating systems (most widely: Windows) this results in a denial of service when the affected process hangs. Policy processing being enabled on a publicly facing server is not considered to be a common setup. Policy processing is enabled by passing the -policy' argument to the command line utilities or by calling eitherX509_VERIFY_PARAM_add0_policy()' or `X509_VERIFY_PARAM_set1_policies()' functions.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "openssl-src"
},
"ranges": [
{
"events": [
{
"introduced": "300.0.0"
},
{
"fixed": "300.0.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-3996"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2023-05-02T16:35:23Z",
"nvd_published_at": "2022-12-13T16:15:00Z",
"severity": "HIGH"
},
"details": "If an X.509 certificate contains a malformed policy constraint and policy processing is enabled, then a write lock will be taken twice recursively. On some operating systems (most widely: Windows) this results in a denial of service when the affected process hangs. Policy processing being enabled on a publicly facing server is not considered to be a common setup. Policy processing is enabled by passing the `-policy\u0027 argument to the command line utilities or by calling either `X509_VERIFY_PARAM_add0_policy()\u0027 or `X509_VERIFY_PARAM_set1_policies()\u0027 functions.",
"id": "GHSA-vr8j-hgmm-jh9r",
"modified": "2024-10-02T18:03:42Z",
"published": "2022-12-13T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3996"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/7725e7bfe6f2ce8146b6552b44e0d226be7638e7"
},
{
"type": "PACKAGE",
"url": "https://github.com/alexcrichton/openssl-src-rs"
},
{
"type": "WEB",
"url": "https://www.openssl.org/news/secadv/20221213.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Denial of service by double-checked locking in openssl-src"
}
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.