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.
729 vulnerabilities reference this CWE, most recent first.
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"
}
GHSA-VW3G-79H8-V7F8
Vulnerability from github – Published: 2024-03-01 00:30 – Updated: 2024-12-10 21:30In the Linux kernel, the following vulnerability has been resolved:
soc/tegra: regulators: Fix locking up when voltage-spread is out of range
Fix voltage coupler lockup which happens when voltage-spread is out of range due to a bug in the code. The max-spread requirement shall be accounted when CPU regulator doesn't have consumers. This problem is observed on Tegra30 Ouya game console once system-wide DVFS is enabled in a device-tree.
{
"affected": [],
"aliases": [
"CVE-2021-47067"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-29T23:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc/tegra: regulators: Fix locking up when voltage-spread is out of range\n\nFix voltage coupler lockup which happens when voltage-spread is out\nof range due to a bug in the code. The max-spread requirement shall be\naccounted when CPU regulator doesn\u0027t have consumers. This problem is\nobserved on Tegra30 Ouya game console once system-wide DVFS is enabled\nin a device-tree.",
"id": "GHSA-vw3g-79h8-v7f8",
"modified": "2024-12-10T21:30:51Z",
"published": "2024-03-01T00:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47067"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1ad124c836816fac8bd5e461d36eaf33cee4e24"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dc4452867200fa94589b382740952b58aa1c3e6c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef85bb582c41524e9e68dfdbde48e519dac4ab3d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff39adf5d31c72025bba799aec69c5c86d81d549"
}
],
"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-VW3M-PVF6-GXW8
Vulnerability from github – Published: 2024-04-17 12:32 – Updated: 2024-04-29 21:30In the Linux kernel, the following vulnerability has been resolved:
block: fix deadlock between bd_link_disk_holder and partition scan
'open_mutex' of gendisk is used to protect open/close block devices. But in bd_link_disk_holder(), it is used to protect the creation of symlink between holding disk and slave bdev, which introduces some issues.
When bd_link_disk_holder() is called, the driver is usually in the process of initialization/modification and may suspend submitting io. At this time, any io hold 'open_mutex', such as scanning partitions, can cause deadlocks. For example, in raid:
T1 T2 bdev_open_by_dev lock open_mutex [1] ... efi_partition ... md_submit_bio md_ioctl mddev_syspend -> suspend all io md_add_new_disk bind_rdev_to_array bd_link_disk_holder try lock open_mutex [2] md_handle_request -> wait mddev_resume
T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume mddev, but T2 waits for open_mutex held by T1. Deadlock occurs.
Fix it by introducing a local mutex 'blk_holder_mutex' to replace 'open_mutex'.
{
"affected": [],
"aliases": [
"CVE-2024-26899"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T11:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix deadlock between bd_link_disk_holder and partition scan\n\n\u0027open_mutex\u0027 of gendisk is used to protect open/close block devices. But\nin bd_link_disk_holder(), it is used to protect the creation of symlink\nbetween holding disk and slave bdev, which introduces some issues.\n\nWhen bd_link_disk_holder() is called, the driver is usually in the process\nof initialization/modification and may suspend submitting io. At this\ntime, any io hold \u0027open_mutex\u0027, such as scanning partitions, can cause\ndeadlocks. For example, in raid:\n\nT1 T2\nbdev_open_by_dev\n lock open_mutex [1]\n ...\n efi_partition\n ...\n md_submit_bio\n\t\t\t\tmd_ioctl mddev_syspend\n\t\t\t\t -\u003e suspend all io\n\t\t\t\t md_add_new_disk\n\t\t\t\t bind_rdev_to_array\n\t\t\t\t bd_link_disk_holder\n\t\t\t\t try lock open_mutex [2]\n md_handle_request\n -\u003e wait mddev_resume\n\nT1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume\nmddev, but T2 waits for open_mutex held by T1. Deadlock occurs.\n\nFix it by introducing a local mutex \u0027blk_holder_mutex\u0027 to replace\n\u0027open_mutex\u0027.",
"id": "GHSA-vw3m-pvf6-gxw8",
"modified": "2024-04-29T21:30:33Z",
"published": "2024-04-17T12:32:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26899"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03f12122b20b6e6028e9ed69030a49f9cffcbb75"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e5c5b0abaee7b62a10b9707a62083b71ad21f62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a87c1f7993bc8ac358a3766bac5dc7126e01e98"
}
],
"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-VW8Q-74W5-57VQ
Vulnerability from github – Published: 2026-06-18 15:32 – Updated: 2026-06-18 18:35[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]
To create and manage guests, domctl operations are used by the control domain, a possible Xenstore domain, or by a domain controlling a particular guest. Some of these operations may not be executed in parallel, so a system-wide lock is used. The way that lock is acquired is, however, not providing any fairness. This is CVE-2026-42489.
Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking. This is CVE-2026-42490.
{
"affected": [],
"aliases": [
"CVE-2026-42489"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-18T14:17:25Z",
"severity": "MODERATE"
},
"details": "[This CNA information record relates to multiple CVEs; the\ntext explains which aspects/vulnerabilities correspond to which CVE.]\n\nTo create and manage guests, domctl operations are used by the control\ndomain, a possible Xenstore domain, or by a domain controlling a\nparticular guest. Some of these operations may not be executed in\nparallel, so a system-wide lock is used. The way that lock is acquired\nis, however, not providing any fairness. This is CVE-2026-42489.\n\nFurthermore, with XSM/Flask in use, the lock acquire will, for some\noperations, occur ahead of any permission checking. This is\nCVE-2026-42490.",
"id": "GHSA-vw8q-74w5-57vq",
"modified": "2026-06-18T18:35:21Z",
"published": "2026-06-18T15:32:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42489"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-492.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-VX82-3VMH-HC4Q
Vulnerability from github – Published: 2022-05-26 00:01 – Updated: 2024-05-03 00:30MariaDB Server before 10.7 is vulnerable to Denial of Service. In extra/mariabackup/ds_xbstream.cc, when an error occurs (stream_ctxt->dest_file == NULL) while executing the method xbstream_open, the held lock is not released correctly, which allows local users to trigger a denial of service due to the deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-31621"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-25T21:15:00Z",
"severity": "MODERATE"
},
"details": "MariaDB Server before 10.7 is vulnerable to Denial of Service. In extra/mariabackup/ds_xbstream.cc, when an error occurs (stream_ctxt-\u003edest_file == NULL) while executing the method xbstream_open, the held lock is not released correctly, which allows local users to trigger a denial of service due to the deadlock.",
"id": "GHSA-vx82-3vmh-hc4q",
"modified": "2024-05-03T00:30:43Z",
"published": "2022-05-26T00:01:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31621"
},
{
"type": "WEB",
"url": "https://github.com/MariaDB/server/commit/b1351c15946349f9daa7e5297fb2ac6f3139e4a8"
},
{
"type": "WEB",
"url": "https://jira.mariadb.org/browse/MDEV-26561"
},
{
"type": "WEB",
"url": "https://jira.mariadb.org/browse/MDEV-26574"
},
{
"type": "WEB",
"url": "https://jira.mariadb.org/browse/MDEV-26574?filter=-2"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220707-0006"
}
],
"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.