GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-667

Allowed-with-Review

Improper 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.

721 vulnerabilities reference this CWE, most recent first.

GHSA-RGGX-C6X2-98G3

Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-28 18:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix exception exit lock checking for subprogs

process_bpf_exit_full() passes check_lock = !curframe to check_resource_leak(), which is false in cases when bpf_throw() is called from a static subprog. This makes check_resource_leak() to skip validation of active_rcu_locks, active_preempt_locks, and active_irq_id on exception exits from subprogs.

At runtime bpf_throw() unwinds the stack via ORC without releasing any user-acquired locks, which may cause various issues as the result.

Fix by setting check_lock = true for exception exits regardless of curframe, since exceptions bypass all intermediate frame cleanup. Update the error message prefix to "bpf_throw" for exception exits to distinguish them from normal BPF_EXIT.

Fix reject_subprog_with_rcu_read_lock test which was previously passing for the wrong reason. Test program returned directly from the subprog call without closing the RCU section, so the error was triggered by the unclosed RCU lock on normal exit, not by bpf_throw. Update __msg annotations for affected tests to match the new "bpf_throw" error prefix.

The spin_lock case is not affected because they are already checked [1] at the call site in do_check_insn() before bpf_throw can run.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/verifier.c?h=v7.0-rc4#n21098

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-31526"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-22T14:16:52Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix exception exit lock checking for subprogs\n\nprocess_bpf_exit_full() passes check_lock = !curframe to\ncheck_resource_leak(), which is false in cases when bpf_throw() is\ncalled from a static subprog. This makes check_resource_leak() to skip\nvalidation of active_rcu_locks, active_preempt_locks, and\nactive_irq_id on exception exits from subprogs.\n\nAt runtime bpf_throw() unwinds the stack via ORC without releasing any\nuser-acquired locks, which may cause various issues as the result.\n\nFix by setting check_lock = true for exception exits regardless of\ncurframe, since exceptions bypass all intermediate frame\ncleanup. Update the error message prefix to \"bpf_throw\" for exception\nexits to distinguish them from normal BPF_EXIT.\n\nFix reject_subprog_with_rcu_read_lock test which was previously\npassing for the wrong reason. Test program returned directly from the\nsubprog call without closing the RCU section, so the error was\ntriggered by the unclosed RCU lock on normal exit, not by\nbpf_throw. Update __msg annotations for affected tests to match the\nnew \"bpf_throw\" error prefix.\n\nThe spin_lock case is not affected because they are already checked [1]\nat the call site in do_check_insn() before bpf_throw can run.\n\n[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/verifier.c?h=v7.0-rc4#n21098",
  "id": "GHSA-rggx-c6x2-98g3",
  "modified": "2026-04-28T18:30:30Z",
  "published": "2026-04-22T15:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31526"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5a399f3117642494e35545f6ca397d3e177c1f9b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6c2128505f61b504c79a20b89596feba61388112"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c0281da1f2aa5c2fca3a05f79b86bea96591c358"
    }
  ],
  "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-RGX6-C7RP-8R4X

Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-06-19 15:33
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

hwmon: (pmbus/core) Protect regulator operations with mutex

The regulator operations pmbus_regulator_get_voltage(), pmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage() access PMBus registers and shared data but were not protected by the update_lock mutex. This could lead to race conditions.

However, adding mutex protection directly to these functions causes a deadlock because pmbus_regulator_notify() (which calls regulator_notifier_call_chain()) is often called with the mutex already held (e.g., from pmbus_fault_handler()). If a regulator callback then calls one of the now-protected voltage functions, it will attempt to acquire the same mutex.

Rework pmbus_regulator_notify() to utilize a worker function to send notifications outside of the mutex protection. Events are stored as atomics in a per-page bitmask and processed by the worker.

Initialize the worker and its associated data during regulator registration, and ensure it is cancelled on device removal using devm_add_action_or_reset().

While at it, remove the unnecessary include of linux/of.h.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-31486"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-22T14:16:46Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (pmbus/core) Protect regulator operations with mutex\n\nThe regulator operations pmbus_regulator_get_voltage(),\npmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage()\naccess PMBus registers and shared data but were not protected by\nthe update_lock mutex. This could lead to race conditions.\n\nHowever, adding mutex protection directly to these functions causes\na deadlock because pmbus_regulator_notify() (which calls\nregulator_notifier_call_chain()) is often called with the mutex\nalready held (e.g., from pmbus_fault_handler()). If a regulator\ncallback then calls one of the now-protected voltage functions,\nit will attempt to acquire the same mutex.\n\nRework pmbus_regulator_notify() to utilize a worker function to\nsend notifications outside of the mutex protection. Events are\nstored as atomics in a per-page bitmask and processed by the worker.\n\nInitialize the worker and its associated data during regulator\nregistration, and ensure it is cancelled on device removal using\ndevm_add_action_or_reset().\n\nWhile at it, remove the unnecessary include of linux/of.h.",
  "id": "GHSA-rgx6-c7rp-8r4x",
  "modified": "2026-06-19T15:33:08Z",
  "published": "2026-04-22T15:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31486"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2c77ae315f3ce9d2c8e1609be74c9358c1fe4e07"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4e9d723d9f198b86f6882a84c501ba1f39e8d055"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/754bd2b4a084b90b5e7b630e1f423061a9b9b761"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/acf04e2863132f6d9222f71f3a76fb9782cbe061"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b26849cffaa7c43355b82e9bef3725e786973a1a"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RH96-4PX7-3VM8

Vulnerability from github – Published: 2024-06-21 12:31 – Updated: 2026-05-12 12:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

dma-buf/sw-sync: don't enable IRQ from sync_print_obj()

Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning.

Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-38780"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-21T12:15:11Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf/sw-sync: don\u0027t enable IRQ from sync_print_obj()\n\nSince commit a6aa8fca4d79 (\"dma-buf/sw-sync: Reduce irqsave/irqrestore from\nknown context\") by error replaced spin_unlock_irqrestore() with\nspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite\nsync_print_obj() is called from sync_debugfs_show(), lockdep complains\ninconsistent lock state warning.\n\nUse plain spin_{lock,unlock}() for sync_print_obj(), for\nsync_debugfs_show() is already using spin_{lock,unlock}_irq().",
  "id": "GHSA-rh96-4px7-3vm8",
  "modified": "2026-05-12T12:31:57Z",
  "published": "2024-06-21T12:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38780"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/165b25e3ee9333f7b04f8db43895beacb51582ed"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1ff116f68560a25656933d5a18e7619cb6773d8a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/242b30466879e6defa521573c27e12018276c33a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8a283cdfc8beeb14024387a925247b563d614e1e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9d75fab2c14a25553a1664586ed122c316bd1878"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a4ee78244445ab73af22bfc5a5fc543963b25aef"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ae6fc4e6a3322f6d1c8ff59150d8469487a73dd8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b794918961516f667b0c745aebdfebbb8a98df39"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
    }
  ],
  "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-RJ28-PP8G-VC2R

Vulnerability from github – Published: 2024-06-24 15:31 – Updated: 2024-06-26 15:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

drm: zynqmp_dpsub: Always register bridge

We must always register the DRM bridge, since zynqmp_dp_hpd_work_func calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be initialized. We do this before zynqmp_dpsub_drm_init since that calls drm_bridge_attach. This fixes the following lockdep warning:

[ 19.217084] ------------[ cut here ]------------ [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550 [ 19.241696] Modules linked in: [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96 [ 19.252046] Hardware name: xlnx,zynqmp (DT) [ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.269104] pc : __mutex_lock+0x4bc/0x550 [ 19.273364] lr : __mutex_lock+0x4bc/0x550 [ 19.277592] sp : ffffffc085c5bbe0 [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8 [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000 [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888 [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000 [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 [ 19.356581] Call trace: [ 19.359160] __mutex_lock+0x4bc/0x550 [ 19.363032] mutex_lock_nested+0x24/0x30 [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c [ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54 [ 19.376364] process_one_work+0x3ac/0x988 [ 19.380660] worker_thread+0x398/0x694 [ 19.384736] kthread+0x1bc/0x1c0 [ 19.388241] ret_from_fork+0x10/0x20 [ 19.392031] irq event stamp: 183 [ 19.395450] hardirqs last enabled at (183): [] finish_task_switch.isra.0+0xa8/0x2d4 [ 19.405140] hardirqs last disabled at (182): [] __schedule+0x714/0xd04 [ 19.413612] softirqs last enabled at (114): [] srcu_invoke_callbacks+0x158/0x23c [ 19.423128] softirqs last disabled at (110): [] srcu_invoke_callbacks+0x158/0x23c [ 19.432614] ---[ end trace 0000000000000000 ]---

(cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-38664"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-24T14:15:12Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: zynqmp_dpsub: Always register bridge\n\nWe must always register the DRM bridge, since zynqmp_dp_hpd_work_func\ncalls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be\ninitialized. We do this before zynqmp_dpsub_drm_init since that calls\ndrm_bridge_attach. This fixes the following lockdep warning:\n\n[   19.217084] ------------[ cut here ]------------\n[   19.227530] DEBUG_LOCKS_WARN_ON(lock-\u003emagic != lock)\n[   19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550\n[   19.241696] Modules linked in:\n[   19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96\n[   19.252046] Hardware name: xlnx,zynqmp (DT)\n[   19.256421] Workqueue: events zynqmp_dp_hpd_work_func\n[   19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   19.269104] pc : __mutex_lock+0x4bc/0x550\n[   19.273364] lr : __mutex_lock+0x4bc/0x550\n[   19.277592] sp : ffffffc085c5bbe0\n[   19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8\n[   19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000\n[   19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000\n[   19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000\n[   19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720\n[   19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001\n[   19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888\n[   19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000\n[   19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000\n[   19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880\n[   19.356581] Call trace:\n[   19.359160]  __mutex_lock+0x4bc/0x550\n[   19.363032]  mutex_lock_nested+0x24/0x30\n[   19.367187]  drm_bridge_hpd_notify+0x2c/0x6c\n[   19.371698]  zynqmp_dp_hpd_work_func+0x44/0x54\n[   19.376364]  process_one_work+0x3ac/0x988\n[   19.380660]  worker_thread+0x398/0x694\n[   19.384736]  kthread+0x1bc/0x1c0\n[   19.388241]  ret_from_fork+0x10/0x20\n[   19.392031] irq event stamp: 183\n[   19.395450] hardirqs last  enabled at (183): [\u003cffffffc0800b9278\u003e] finish_task_switch.isra.0+0xa8/0x2d4\n[   19.405140] hardirqs last disabled at (182): [\u003cffffffc081ad3754\u003e] __schedule+0x714/0xd04\n[   19.413612] softirqs last  enabled at (114): [\u003cffffffc080133de8\u003e] srcu_invoke_callbacks+0x158/0x23c\n[   19.423128] softirqs last disabled at (110): [\u003cffffffc080133de8\u003e] srcu_invoke_callbacks+0x158/0x23c\n[   19.432614] ---[ end trace 0000000000000000 ]---\n\n(cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)",
  "id": "GHSA-rj28-pp8g-vc2r",
  "modified": "2024-06-26T15:31:01Z",
  "published": "2024-06-24T15:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38664"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/603661357056b5e5ba6d86f505fbc936eff396ba"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6ead3eccf67bc8318b1ce95ed879b2cc05b4fce9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/be3f3042391d061cfca2bd22630e0d101acea5fc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RJPX-6FRC-3VGP

Vulnerability from github – Published: 2025-05-09 09:33 – Updated: 2025-11-17 15:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

PCI: pciehp: Avoid unnecessary device replacement check

Hot-removal of nested PCI hotplug ports suffers from a long-standing race condition which can lead to a deadlock: A parent hotplug port acquires pci_lock_rescan_remove(), then waits for pciehp to unbind from a child hotplug port. Meanwhile that child hotplug port tries to acquire pci_lock_rescan_remove() as well in order to remove its own children.

The deadlock only occurs if the parent acquires pci_lock_rescan_remove() first, not if the child happens to acquire it first.

Several workarounds to avoid the issue have been proposed and discarded over the years, e.g.:

https://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/

A proper fix is being worked on, but needs more time as it is nontrivial and necessarily intrusive.

Recent commit 9d573d19547b ("PCI: pciehp: Detect device replacement during system sleep") provokes more frequent occurrence of the deadlock when removing more than one Thunderbolt device during system sleep. The commit sought to detect device replacement, but also triggered on device removal. Differentiating reliably between replacement and removal is impossible because pci_get_dsn() returns 0 both if the device was removed, as well as if it was replaced with one lacking a Device Serial Number.

Avoid the more frequent occurrence of the deadlock by checking whether the hotplug port itself was hot-removed. If so, there's no sense in checking whether its child device was replaced.

This works because the ->resume_noirq() callback is invoked in top-down order for the entire hierarchy: A parent hotplug port detecting device replacement (or removal) marks all children as removed using pci_dev_set_disconnected() and a child hotplug port can then reliably detect being removed.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-37843"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-09T07:16:05Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: pciehp: Avoid unnecessary device replacement check\n\nHot-removal of nested PCI hotplug ports suffers from a long-standing race\ncondition which can lead to a deadlock:  A parent hotplug port acquires\npci_lock_rescan_remove(), then waits for pciehp to unbind from a child\nhotplug port.  Meanwhile that child hotplug port tries to acquire\npci_lock_rescan_remove() as well in order to remove its own children.\n\nThe deadlock only occurs if the parent acquires pci_lock_rescan_remove()\nfirst, not if the child happens to acquire it first.\n\nSeveral workarounds to avoid the issue have been proposed and discarded\nover the years, e.g.:\n\nhttps://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/\n\nA proper fix is being worked on, but needs more time as it is nontrivial\nand necessarily intrusive.\n\nRecent commit 9d573d19547b (\"PCI: pciehp: Detect device replacement during\nsystem sleep\") provokes more frequent occurrence of the deadlock when\nremoving more than one Thunderbolt device during system sleep.  The commit\nsought to detect device replacement, but also triggered on device removal.\nDifferentiating reliably between replacement and removal is impossible\nbecause pci_get_dsn() returns 0 both if the device was removed, as well as\nif it was replaced with one lacking a Device Serial Number.\n\nAvoid the more frequent occurrence of the deadlock by checking whether the\nhotplug port itself was hot-removed.  If so, there\u0027s no sense in checking\nwhether its child device was replaced.\n\nThis works because the -\u003eresume_noirq() callback is invoked in top-down\norder for the entire hierarchy:  A parent hotplug port detecting device\nreplacement (or removal) marks all children as removed using\npci_dev_set_disconnected() and a child hotplug port can then reliably\ndetect being removed.",
  "id": "GHSA-rjpx-6frc-3vgp",
  "modified": "2025-11-17T15:30:30Z",
  "published": "2025-05-09T09:33:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37843"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0d0bbd01f7c0ac7d1be9f85aaf2cd0baec34655f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7535d10a2c61baeff493300070cf04d9ddda216b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e3260237aaadc9799107ccb940c6688195c4518d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e4a1d7defbc2d806540720a5adebe24ec3488683"
    }
  ],
  "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-RP89-9JXH-73FW

Vulnerability from github – Published: 2024-09-27 15:30 – Updated: 2024-10-01 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

drm/xe/client: fix deadlock in show_meminfo()

There is a real deadlock as well as sleeping in atomic() bug in here, if the bo put happens to be the last ref, since bo destruction wants to grab the same spinlock and sleeping locks. Fix that by dropping the ref using xe_bo_put_deferred(), and moving the final commit outside of the lock. Dropping the lock around the put is tricky since the bo can go out of scope and delete itself from the list, making it difficult to navigate to the next list entry.

(cherry picked from commit 0083b8e6f11d7662283a267d4ce7c966812ffd8a)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-46867"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-27T13:15:17Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/client: fix deadlock in show_meminfo()\n\nThere is a real deadlock as well as sleeping in atomic() bug in here, if\nthe bo put happens to be the last ref, since bo destruction wants to\ngrab the same spinlock and sleeping locks.  Fix that by dropping the ref\nusing xe_bo_put_deferred(), and moving the final commit outside of the\nlock. Dropping the lock around the put is tricky since the bo can go\nout of scope and delete itself from the list, making it difficult to\nnavigate to the next list entry.\n\n(cherry picked from commit 0083b8e6f11d7662283a267d4ce7c966812ffd8a)",
  "id": "GHSA-rp89-9jxh-73fw",
  "modified": "2024-10-01T18:31:17Z",
  "published": "2024-09-27T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46867"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9bd7ff293fc84792514aeafa06c5a17f05cb5f4b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9d3de463e23bfb1ff1567a32b099b1b3e5286a48"
    }
  ],
  "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-RPXC-PCJP-7JP2

Vulnerability from github – Published: 2025-07-10 09:32 – Updated: 2025-11-20 00:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

fs/dax: Fix "don't skip locked entries when scanning entries"

Commit 6be3e21d25ca ("fs/dax: don't skip locked entries when scanning entries") introduced a new function, wait_entry_unlocked_exclusive(), which waits for the current entry to become unlocked without advancing the XArray iterator state.

Waiting for the entry to become unlocked requires dropping the XArray lock. This requires calling xas_pause() prior to dropping the lock which leaves the xas in a suitable state for the next iteration. However this has the side-effect of advancing the xas state to the next index. Normally this isn't an issue because xas_for_each() contains code to detect this state and thus avoid advancing the index a second time on the next loop iteration.

However both callers of and wait_entry_unlocked_exclusive() itself subsequently use the xas state to reload the entry. As xas_pause() updated the state to the next index this will cause the current entry which is being waited on to be skipped. This caused the following warning to fire intermittently when running xftest generic/068 on an XFS filesystem with FS DAX enabled:

[ 35.067397] ------------[ cut here ]------------ [ 35.068229] WARNING: CPU: 21 PID: 1640 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0xd8/0x1e0 [ 35.069717] Modules linked in: nd_pmem dax_pmem nd_btt nd_e820 libnvdimm [ 35.071006] CPU: 21 UID: 0 PID: 1640 Comm: fstest Not tainted 6.15.0-rc7+ #77 PREEMPT(voluntary) [ 35.072613] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/204 [ 35.074845] RIP: 0010:truncate_folio_batch_exceptionals+0xd8/0x1e0 [ 35.075962] Code: a1 00 00 00 f6 47 0d 20 0f 84 97 00 00 00 4c 63 e8 41 39 c4 7f 0b eb 61 49 83 c5 01 45 39 ec 7e 58 42 f68 [ 35.079522] RSP: 0018:ffffb04e426c7850 EFLAGS: 00010202 [ 35.080359] RAX: 0000000000000000 RBX: ffff9d21e3481908 RCX: ffffb04e426c77f4 [ 35.081477] RDX: ffffb04e426c79e8 RSI: ffffb04e426c79e0 RDI: ffff9d21e34816e8 [ 35.082590] RBP: ffffb04e426c79e0 R08: 0000000000000001 R09: 0000000000000003 [ 35.083733] R10: 0000000000000000 R11: 822b53c0f7a49868 R12: 000000000000001f [ 35.084850] R13: 0000000000000000 R14: ffffb04e426c78e8 R15: fffffffffffffffe [ 35.085953] FS: 00007f9134c87740(0000) GS:ffff9d22abba0000(0000) knlGS:0000000000000000 [ 35.087346] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 35.088244] CR2: 00007f9134c86000 CR3: 000000040afff000 CR4: 00000000000006f0 [ 35.089354] Call Trace: [ 35.089749] [ 35.090168] truncate_inode_pages_range+0xfc/0x4d0 [ 35.091078] truncate_pagecache+0x47/0x60 [ 35.091735] xfs_setattr_size+0xc7/0x3e0 [ 35.092648] xfs_vn_setattr+0x1ea/0x270 [ 35.093437] notify_change+0x1f4/0x510 [ 35.094219] ? do_truncate+0x97/0xe0 [ 35.094879] do_truncate+0x97/0xe0 [ 35.095640] path_openat+0xabd/0xca0 [ 35.096278] do_filp_open+0xd7/0x190 [ 35.096860] do_sys_openat2+0x8a/0xe0 [ 35.097459] __x64_sys_openat+0x6d/0xa0 [ 35.098076] do_syscall_64+0xbb/0x1d0 [ 35.098647] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 35.099444] RIP: 0033:0x7f9134d81fc1 [ 35.100033] Code: 75 57 89 f0 25 00 00 41 00 3d 00 00 41 00 74 49 80 3d 2a 26 0e 00 00 74 6d 89 da 48 89 ee bf 9c ff ff ff5 [ 35.102993] RSP: 002b:00007ffcd41e0d10 EFLAGS: 00000202 ORIG_RAX: 0000000000000101 [ 35.104263] RAX: ffffffffffffffda RBX: 0000000000000242 RCX: 00007f9134d81fc1 [ 35.105452] RDX: 0000000000000242 RSI: 00007ffcd41e1200 RDI: 00000000ffffff9c [ 35.106663] RBP: 00007ffcd41e1200 R08: 0000000000000000 R09: 0000000000000064 [ 35.107923] R10: 00000000000001a4 R11: 0000000000000202 R12: 0000000000000066 [ 35.109112] R13: 0000000000100000 R14: 0000000000100000 R15: 0000000000000400 [ 35.110357] [ 35.110769] irq event stamp: 8415587 [ 35.111486] hardirqs last enabled at (8415599): [] __up_console_se ---truncated---

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-38276"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-10T08:15:25Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/dax: Fix \"don\u0027t skip locked entries when scanning entries\"\n\nCommit 6be3e21d25ca (\"fs/dax: don\u0027t skip locked entries when scanning\nentries\") introduced a new function, wait_entry_unlocked_exclusive(),\nwhich waits for the current entry to become unlocked without advancing\nthe XArray iterator state.\n\nWaiting for the entry to become unlocked requires dropping the XArray\nlock. This requires calling xas_pause() prior to dropping the lock\nwhich leaves the xas in a suitable state for the next iteration. However\nthis has the side-effect of advancing the xas state to the next index.\nNormally this isn\u0027t an issue because xas_for_each() contains code to\ndetect this state and thus avoid advancing the index a second time on\nthe next loop iteration.\n\nHowever both callers of and wait_entry_unlocked_exclusive() itself\nsubsequently use the xas state to reload the entry. As xas_pause()\nupdated the state to the next index this will cause the current entry\nwhich is being waited on to be skipped. This caused the following\nwarning to fire intermittently when running xftest generic/068 on an XFS\nfilesystem with FS DAX enabled:\n\n[   35.067397] ------------[ cut here ]------------\n[   35.068229] WARNING: CPU: 21 PID: 1640 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0xd8/0x1e0\n[   35.069717] Modules linked in: nd_pmem dax_pmem nd_btt nd_e820 libnvdimm\n[   35.071006] CPU: 21 UID: 0 PID: 1640 Comm: fstest Not tainted 6.15.0-rc7+ #77 PREEMPT(voluntary)\n[   35.072613] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/204\n[   35.074845] RIP: 0010:truncate_folio_batch_exceptionals+0xd8/0x1e0\n[   35.075962] Code: a1 00 00 00 f6 47 0d 20 0f 84 97 00 00 00 4c 63 e8 41 39 c4 7f 0b eb 61 49 83 c5 01 45 39 ec 7e 58 42 f68\n[   35.079522] RSP: 0018:ffffb04e426c7850 EFLAGS: 00010202\n[   35.080359] RAX: 0000000000000000 RBX: ffff9d21e3481908 RCX: ffffb04e426c77f4\n[   35.081477] RDX: ffffb04e426c79e8 RSI: ffffb04e426c79e0 RDI: ffff9d21e34816e8\n[   35.082590] RBP: ffffb04e426c79e0 R08: 0000000000000001 R09: 0000000000000003\n[   35.083733] R10: 0000000000000000 R11: 822b53c0f7a49868 R12: 000000000000001f\n[   35.084850] R13: 0000000000000000 R14: ffffb04e426c78e8 R15: fffffffffffffffe\n[   35.085953] FS:  00007f9134c87740(0000) GS:ffff9d22abba0000(0000) knlGS:0000000000000000\n[   35.087346] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   35.088244] CR2: 00007f9134c86000 CR3: 000000040afff000 CR4: 00000000000006f0\n[   35.089354] Call Trace:\n[   35.089749]  \u003cTASK\u003e\n[   35.090168]  truncate_inode_pages_range+0xfc/0x4d0\n[   35.091078]  truncate_pagecache+0x47/0x60\n[   35.091735]  xfs_setattr_size+0xc7/0x3e0\n[   35.092648]  xfs_vn_setattr+0x1ea/0x270\n[   35.093437]  notify_change+0x1f4/0x510\n[   35.094219]  ? do_truncate+0x97/0xe0\n[   35.094879]  do_truncate+0x97/0xe0\n[   35.095640]  path_openat+0xabd/0xca0\n[   35.096278]  do_filp_open+0xd7/0x190\n[   35.096860]  do_sys_openat2+0x8a/0xe0\n[   35.097459]  __x64_sys_openat+0x6d/0xa0\n[   35.098076]  do_syscall_64+0xbb/0x1d0\n[   35.098647]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[   35.099444] RIP: 0033:0x7f9134d81fc1\n[   35.100033] Code: 75 57 89 f0 25 00 00 41 00 3d 00 00 41 00 74 49 80 3d 2a 26 0e 00 00 74 6d 89 da 48 89 ee bf 9c ff ff ff5\n[   35.102993] RSP: 002b:00007ffcd41e0d10 EFLAGS: 00000202 ORIG_RAX: 0000000000000101\n[   35.104263] RAX: ffffffffffffffda RBX: 0000000000000242 RCX: 00007f9134d81fc1\n[   35.105452] RDX: 0000000000000242 RSI: 00007ffcd41e1200 RDI: 00000000ffffff9c\n[   35.106663] RBP: 00007ffcd41e1200 R08: 0000000000000000 R09: 0000000000000064\n[   35.107923] R10: 00000000000001a4 R11: 0000000000000202 R12: 0000000000000066\n[   35.109112] R13: 0000000000100000 R14: 0000000000100000 R15: 0000000000000400\n[   35.110357]  \u003c/TASK\u003e\n[   35.110769] irq event stamp: 8415587\n[   35.111486] hardirqs last  enabled at (8415599): [\u003cffffffff8d74b562\u003e] __up_console_se\n---truncated---",
  "id": "GHSA-rpxc-pcjp-7jp2",
  "modified": "2025-11-20T00:31:20Z",
  "published": "2025-07-10T09:32:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38276"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/61009dd2252ab4391d44a240e891f1e04c00b9ca"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dd59137bfe70cf3646021b4721e430213b9c71bd"
    }
  ],
  "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-RQ2W-C7M2-92HW

Vulnerability from github – Published: 2022-05-24 16:52 – Updated: 2022-05-24 16:52
VLAI
Details

In the Linux kernel before 4.16.4, a double-locking error in drivers/usb/dwc3/gadget.c may potentially cause a deadlock with f_hid.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-14763"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-07T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel before 4.16.4, a double-locking error in drivers/usb/dwc3/gadget.c may potentially cause a deadlock with f_hid.",
  "id": "GHSA-rq2w-c7m2-92hw",
  "modified": "2022-05-24T16:52:54Z",
  "published": "2022-05-24T16:52:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14763"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/072684e8c58d17e853f8e8b9f6d9ce2e58d2b036"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/c91815b596245fd7da349ecc43c8def670d2269e"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.16.4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=072684e8c58d17e853f8e8b9f6d9ce2e58d2b036"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c91815b596245fd7da349ecc43c8def670d2269e"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4115-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4118-1"
    },
    {
      "type": "WEB",
      "url": "https://www.spinics.net/lists/linux-usb/msg167355.html"
    },
    {
      "type": "WEB",
      "url": "https://www.spinics.net/lists/linux-usb/msg167393.html"
    }
  ],
  "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-V28G-2C4F-RJXR

Vulnerability from github – Published: 2026-03-03 03:32 – Updated: 2026-03-03 03:32
VLAI
Details

Improper Locking vulnerability (CWE-667) in Gallagher Morpho integration allows a privileged operator to cause a limited denial-of-service in the Command Centre Server.

This issue affects Command Centre Server:

9.40 prior to vEL9.40.1976(MR1), 9.30 prior to vEL9.30.3382 (MR4), 9.20 prior to vEL9.20.3783 (MR6), 9.10 prior to vEL9.10.4647 (MR9), all versions of 9.00 and prior.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-20757"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-03T03:15:54Z",
    "severity": "LOW"
  },
  "details": "Improper Locking\u00a0vulnerability (CWE-667) in\u00a0Gallagher Morpho integration allows a privileged operator to cause a limited denial-of-service in the Command Centre Server.\n\n\n\nThis issue affects Command Centre Server: \n\n9.40 prior to vEL9.40.1976(MR1), 9.30 prior to vEL9.30.3382 (MR4), 9.20 prior to vEL9.20.3783 (MR6), 9.10 prior to vEL9.10.4647 (MR9), all versions of 9.00 and prior.",
  "id": "GHSA-v28g-2c4f-rjxr",
  "modified": "2026-03-03T03:32:42Z",
  "published": "2026-03-03T03:32:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20757"
    },
    {
      "type": "WEB",
      "url": "https://security.gallagher.com/en-NZ/Security-Advisories/CVE-2026-20757"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V2QV-W894-WVXX

Vulnerability from github – Published: 2025-05-08 09:30 – Updated: 2025-11-13 00:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

usb: cdns3: Fix deadlock when using NCM gadget

The cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit 58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget").

Under PREEMPT_RT the deadlock can be readily triggered by heavy network traffic, for example using "iperf --bidir" over NCM ethernet link.

The deadlock occurs because the threaded interrupt handler gets preempted by a softirq, but both are protected by the same spinlock. Prevent deadlock by disabling softirq during threaded irq handler.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-37812"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-08T07:15:52Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: Fix deadlock when using NCM gadget\n\nThe cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit\n58f2fcb3a845 (\"usb: cdnsp: Fix deadlock issue during using NCM gadget\").\n\nUnder PREEMPT_RT the deadlock can be readily triggered by heavy network\ntraffic, for example using \"iperf --bidir\" over NCM ethernet link.\n\nThe deadlock occurs because the threaded interrupt handler gets\npreempted by a softirq, but both are protected by the same spinlock.\nPrevent deadlock by disabling softirq during threaded irq handler.",
  "id": "GHSA-v2qv-w894-wvxx",
  "modified": "2025-11-13T00:30:16Z",
  "published": "2025-05-08T09:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37812"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/09e90a9689a4aac7a2f726dc2aa472b0b37937b7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/48a62deb857f0694f611949015e70ad194d97159"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/59a760e4796a3cd88d8b9d7706e0a638de677751"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/74cd6e408a4c010e404832f0e4609d29bf1d0c41"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a1059896f2bfdcebcdc7153c3be2307ea319501f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b96239582531775f2fdcb14de29bdb6870fd4c8c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c27db84ed44e50ff90d9e3a2a25fae2e0a0fa015"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/eebfb64c624fc738b669100173344fb441c5e719"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
    }
  ],
  "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
Implementation

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.