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.
693 vulnerabilities reference this CWE, most recent first.
GHSA-VH5C-FH26-4H3R
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-06-03 18:55In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled
When I did hard offline test with hugetlb pages, below deadlock occurs:
====================================================== WARNING: possible circular locking dependency detected 6.8.0-11409-gf6cef5f8c37f #1 Not tainted
bash/46904 is trying to acquire lock: ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60
but task is already holding lock: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (pcp_batch_high_lock){+.+.}-{3:3}: __mutex_lock+0x6c/0x770 page_alloc_cpu_online+0x3c/0x70 cpuhp_invoke_callback+0x397/0x5f0 __cpuhp_invoke_callback_range+0x71/0xe0 _cpu_up+0xeb/0x210 cpu_up+0x91/0xe0 cpuhp_bringup_mask+0x49/0xb0 bringup_nonboot_cpus+0xb7/0xe0 smp_init+0x25/0xa0 kernel_init_freeable+0x15f/0x3e0 kernel_init+0x15/0x1b0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30
-> #0 (cpu_hotplug_lock){++++}-{0:0}: __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(pcp_batch_high_lock); lock(cpu_hotplug_lock); lock(pcp_batch_high_lock); rlock(cpu_hotplug_lock);
*** DEADLOCK ***
5 locks held by bash/46904: #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70 #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
stack backtrace: CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 check_noncircular+0x129/0x140 __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fc862314887 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887 RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001 RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00
In short, below scene breaks the ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26987"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled\n\nWhen I did hard offline test with hugetlb pages, below deadlock occurs:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.8.0-11409-gf6cef5f8c37f #1 Not tainted\n------------------------------------------------------\nbash/46904 is trying to acquire lock:\nffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60\n\nbut task is already holding lock:\nffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #1 (pcp_batch_high_lock){+.+.}-{3:3}:\n __mutex_lock+0x6c/0x770\n page_alloc_cpu_online+0x3c/0x70\n cpuhp_invoke_callback+0x397/0x5f0\n __cpuhp_invoke_callback_range+0x71/0xe0\n _cpu_up+0xeb/0x210\n cpu_up+0x91/0xe0\n cpuhp_bringup_mask+0x49/0xb0\n bringup_nonboot_cpus+0xb7/0xe0\n smp_init+0x25/0xa0\n kernel_init_freeable+0x15f/0x3e0\n kernel_init+0x15/0x1b0\n ret_from_fork+0x2f/0x50\n ret_from_fork_asm+0x1a/0x30\n\n-\u003e #0 (cpu_hotplug_lock){++++}-{0:0}:\n __lock_acquire+0x1298/0x1cd0\n lock_acquire+0xc0/0x2b0\n cpus_read_lock+0x2a/0xc0\n static_key_slow_dec+0x16/0x60\n __hugetlb_vmemmap_restore_folio+0x1b9/0x200\n dissolve_free_huge_page+0x211/0x260\n __page_handle_poison+0x45/0xc0\n memory_failure+0x65e/0xc70\n hard_offline_page_store+0x55/0xa0\n kernfs_fop_write_iter+0x12c/0x1d0\n vfs_write+0x387/0x550\n ksys_write+0x64/0xe0\n do_syscall_64+0xca/0x1e0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(pcp_batch_high_lock);\n lock(cpu_hotplug_lock);\n lock(pcp_batch_high_lock);\n rlock(cpu_hotplug_lock);\n\n *** DEADLOCK ***\n\n5 locks held by bash/46904:\n #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0\n #1: ffff98f6c328e488 (\u0026of-\u003emutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0\n #2: ffff98ef83b31890 (kn-\u003eactive#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0\n #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70\n #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40\n\nstack backtrace:\nCPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x68/0xa0\n check_noncircular+0x129/0x140\n __lock_acquire+0x1298/0x1cd0\n lock_acquire+0xc0/0x2b0\n cpus_read_lock+0x2a/0xc0\n static_key_slow_dec+0x16/0x60\n __hugetlb_vmemmap_restore_folio+0x1b9/0x200\n dissolve_free_huge_page+0x211/0x260\n __page_handle_poison+0x45/0xc0\n memory_failure+0x65e/0xc70\n hard_offline_page_store+0x55/0xa0\n kernfs_fop_write_iter+0x12c/0x1d0\n vfs_write+0x387/0x550\n ksys_write+0x64/0xe0\n do_syscall_64+0xca/0x1e0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7fc862314887\nCode: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 \u003c48\u003e 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24\nRSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887\nRDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001\nRBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff\nR10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c\nR13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00\n\nIn short, below scene breaks the \n---truncated---",
"id": "GHSA-vh5c-fh26-4h3r",
"modified": "2024-06-03T18:55:51Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26987"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1983184c22dd84a4d95a71e5c6775c2638557dc7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49955b24002dc16a0ae2e83a57a2a6c863a1845c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5ef7ba2799a3b5ed292b8f6407376e2c25ef002e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/882e1180c83f5b75bae03d0ccc31ccedfe5159de"
},
{
"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-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.