CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
713 vulnerabilities reference this CWE, most recent first.
GHSA-4QCC-96J2-GV42
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2025-02-03 18:30In the Linux kernel, the following vulnerability has been resolved:
ice: fix LAG and VF lock dependency in ice_reset_vf()
9f74a3dfcf83 ("ice: Fix VF Reset paths when interface in a failed over aggregate"), the ice driver has acquired the LAG mutex in ice_reset_vf(). The commit placed this lock acquisition just prior to the acquisition of the VF configuration lock.
If ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK flag, this could deadlock with ice_vc_cfg_qs_msg() because it always acquires the locks in the order of the VF configuration lock and then the LAG mutex.
Lockdep reports this violation almost immediately on creating and then removing 2 VF:
====================================================== WARNING: possible circular locking dependency detected 6.8.0-rc6 #54 Tainted: G W O
kworker/60:3/6771 is trying to acquire lock: ff40d43e099380a0 (&vf->cfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice]
but task is already holding lock: ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&pf->lag_mutex){+.+.}-{3:3}: __lock_acquire+0x4f8/0xb40 lock_acquire+0xd4/0x2d0 __mutex_lock+0x9b/0xbf0 ice_vc_cfg_qs_msg+0x45/0x690 [ice] ice_vc_process_vf_msg+0x4f5/0x870 [ice] __ice_clean_ctrlq+0x2b5/0x600 [ice] ice_service_task+0x2c9/0x480 [ice] process_one_work+0x1e9/0x4d0 worker_thread+0x1e1/0x3d0 kthread+0x104/0x140 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1b/0x30
-> #0 (&vf->cfg_lock){+.+.}-{3:3}: check_prev_add+0xe2/0xc50 validate_chain+0x558/0x800 __lock_acquire+0x4f8/0xb40 lock_acquire+0xd4/0x2d0 __mutex_lock+0x9b/0xbf0 ice_reset_vf+0x22f/0x4d0 [ice] ice_process_vflr_event+0x98/0xd0 [ice] ice_service_task+0x1cc/0x480 [ice] process_one_work+0x1e9/0x4d0 worker_thread+0x1e1/0x3d0 kthread+0x104/0x140 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1b/0x30
other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&pf->lag_mutex); lock(&vf->cfg_lock); lock(&pf->lag_mutex); lock(&vf->cfg_lock);
*** DEADLOCK *** 4 locks held by kworker/60:3/6771: #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0 #1: ff50d06e05197e58 ((work_completion)(&pf->serv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0 #2: ff40d43ea1960e50 (&pf->vfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice] #3: ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]
stack backtrace: CPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G W O 6.8.0-rc6 #54 Hardware name: Workqueue: ice ice_service_task [ice] Call Trace: dump_stack_lvl+0x4a/0x80 check_noncircular+0x12d/0x150 check_prev_add+0xe2/0xc50 ? save_trace+0x59/0x230 ? add_chain_cache+0x109/0x450 validate_chain+0x558/0x800 __lock_acquire+0x4f8/0xb40 ? lockdep_hardirqs_on+0x7d/0x100 lock_acquire+0xd4/0x2d0 ? ice_reset_vf+0x22f/0x4d0 [ice] ? lock_is_held_type+0xc7/0x120 __mutex_lock+0x9b/0xbf0 ? ice_reset_vf+0x22f/0x4d0 [ice] ? ice_reset_vf+0x22f/0x4d0 [ice] ? rcu_is_watching+0x11/0x50 ? ice_reset_vf+0x22f/0x4d0 [ice] ice_reset_vf+0x22f/0x4d0 [ice] ? process_one_work+0x176/0x4d0 ice_process_vflr_event+0x98/0xd0 [ice] ice_service_task+0x1cc/0x480 [ice] process_one_work+0x1e9/0x4d0 worker_thread+0x1e1/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x104/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30
To avoid deadlock, we must acquire the LAG ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-36003"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix LAG and VF lock dependency in ice_reset_vf()\n\n9f74a3dfcf83 (\"ice: Fix VF Reset paths when interface in a failed over\naggregate\"), the ice driver has acquired the LAG mutex in ice_reset_vf().\nThe commit placed this lock acquisition just prior to the acquisition of\nthe VF configuration lock.\n\nIf ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK\nflag, this could deadlock with ice_vc_cfg_qs_msg() because it always\nacquires the locks in the order of the VF configuration lock and then the\nLAG mutex.\n\nLockdep reports this violation almost immediately on creating and then\nremoving 2 VF:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.8.0-rc6 #54 Tainted: G W O\n------------------------------------------------------\nkworker/60:3/6771 is trying to acquire lock:\nff40d43e099380a0 (\u0026vf-\u003ecfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice]\n\nbut task is already holding lock:\nff40d43ea1961210 (\u0026pf-\u003elag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #1 (\u0026pf-\u003elag_mutex){+.+.}-{3:3}:\n __lock_acquire+0x4f8/0xb40\n lock_acquire+0xd4/0x2d0\n __mutex_lock+0x9b/0xbf0\n ice_vc_cfg_qs_msg+0x45/0x690 [ice]\n ice_vc_process_vf_msg+0x4f5/0x870 [ice]\n __ice_clean_ctrlq+0x2b5/0x600 [ice]\n ice_service_task+0x2c9/0x480 [ice]\n process_one_work+0x1e9/0x4d0\n worker_thread+0x1e1/0x3d0\n kthread+0x104/0x140\n ret_from_fork+0x31/0x50\n ret_from_fork_asm+0x1b/0x30\n\n-\u003e #0 (\u0026vf-\u003ecfg_lock){+.+.}-{3:3}:\n check_prev_add+0xe2/0xc50\n validate_chain+0x558/0x800\n __lock_acquire+0x4f8/0xb40\n lock_acquire+0xd4/0x2d0\n __mutex_lock+0x9b/0xbf0\n ice_reset_vf+0x22f/0x4d0 [ice]\n ice_process_vflr_event+0x98/0xd0 [ice]\n ice_service_task+0x1cc/0x480 [ice]\n process_one_work+0x1e9/0x4d0\n worker_thread+0x1e1/0x3d0\n kthread+0x104/0x140\n ret_from_fork+0x31/0x50\n ret_from_fork_asm+0x1b/0x30\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n CPU0 CPU1\n ---- ----\n lock(\u0026pf-\u003elag_mutex);\n lock(\u0026vf-\u003ecfg_lock);\n lock(\u0026pf-\u003elag_mutex);\n lock(\u0026vf-\u003ecfg_lock);\n\n *** DEADLOCK ***\n4 locks held by kworker/60:3/6771:\n #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0\n #1: ff50d06e05197e58 ((work_completion)(\u0026pf-\u003eserv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0\n #2: ff40d43ea1960e50 (\u0026pf-\u003evfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice]\n #3: ff40d43ea1961210 (\u0026pf-\u003elag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]\n\nstack backtrace:\nCPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G W O 6.8.0-rc6 #54\nHardware name:\nWorkqueue: ice ice_service_task [ice]\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x4a/0x80\n check_noncircular+0x12d/0x150\n check_prev_add+0xe2/0xc50\n ? save_trace+0x59/0x230\n ? add_chain_cache+0x109/0x450\n validate_chain+0x558/0x800\n __lock_acquire+0x4f8/0xb40\n ? lockdep_hardirqs_on+0x7d/0x100\n lock_acquire+0xd4/0x2d0\n ? ice_reset_vf+0x22f/0x4d0 [ice]\n ? lock_is_held_type+0xc7/0x120\n __mutex_lock+0x9b/0xbf0\n ? ice_reset_vf+0x22f/0x4d0 [ice]\n ? ice_reset_vf+0x22f/0x4d0 [ice]\n ? rcu_is_watching+0x11/0x50\n ? ice_reset_vf+0x22f/0x4d0 [ice]\n ice_reset_vf+0x22f/0x4d0 [ice]\n ? process_one_work+0x176/0x4d0\n ice_process_vflr_event+0x98/0xd0 [ice]\n ice_service_task+0x1cc/0x480 [ice]\n process_one_work+0x1e9/0x4d0\n worker_thread+0x1e1/0x3d0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x104/0x140\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u003c/TASK\u003e\n\nTo avoid deadlock, we must acquire the LAG \n---truncated---",
"id": "GHSA-4qcc-96j2-gv42",
"modified": "2025-02-03T18:30:37Z",
"published": "2024-05-20T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36003"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4QCV-J3WR-HW24
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-01-16 15:32In the Linux kernel, the following vulnerability has been resolved:
netfilter: IDLETIMER: Fix for possible ABBA deadlock
Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs:
| ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20 | | but task is already holding lock: | ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v] | | which lock already depends on the new lock.
A simple reproducer is:
| #!/bin/bash |
|---|
| while true; do |
| iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" |
| iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" |
| done & |
| while true; do |
| cat /sys/class/xt_idletimer/timers/testme >/dev/null |
| done |
Avoid this by freeing list_mutex right after deleting the element from the list, then continuing with the teardown.
{
"affected": [],
"aliases": [
"CVE-2024-54683"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: IDLETIMER: Fix for possible ABBA deadlock\n\nDeletion of the last rule referencing a given idletimer may happen at\nthe same time as a read of its file in sysfs:\n\n| ======================================================\n| WARNING: possible circular locking dependency detected\n| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted\n| ------------------------------------------------------\n| iptables/3303 is trying to acquire lock:\n| ffff8881057e04b8 (kn-\u003eactive#48){++++}-{0:0}, at: __kernfs_remove+0x20\n|\n| but task is already holding lock:\n| ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v]\n|\n| which lock already depends on the new lock.\n\nA simple reproducer is:\n\n| #!/bin/bash\n|\n| while true; do\n| iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\"\n| iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\"\n| done \u0026\n| while true; do\n| cat /sys/class/xt_idletimer/timers/testme \u003e/dev/null\n| done\n\nAvoid this by freeing list_mutex right after deleting the element from\nthe list, then continuing with the teardown.",
"id": "GHSA-4qcv-j3wr-hw24",
"modified": "2025-01-16T15:32:09Z",
"published": "2025-01-11T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54683"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45fe76573a2557f632e248cc141342233f422b9a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c2c8445cda8f59c38dec7dc10509bcb23ae26a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f36b01994d68ffc253c8296e2228dfe6e6431c03"
}
],
"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-4R2G-J5RC-7WQF
Vulnerability from github – Published: 2022-03-26 00:00 – Updated: 2024-04-01 15:30A flaw was found in the libvirt nwfilter driver. The virNWFilterObjListNumOfNWFilters method failed to acquire the driver->nwfilters mutex before iterating over virNWFilterObj instances. There was no protection to stop another thread from concurrently modifying the driver->nwfilters object. This flaw allows a malicious, unprivileged user to exploit this issue via libvirt’s API virConnectNumOfNWFilters to crash the network filter management daemon (libvirtd/virtnwfilterd).
{
"affected": [],
"aliases": [
"CVE-2022-0897"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-25T19:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the libvirt nwfilter driver. The virNWFilterObjListNumOfNWFilters method failed to acquire the `driver-\u003enwfilters` mutex before iterating over virNWFilterObj instances. There was no protection to stop another thread from concurrently modifying the `driver-\u003enwfilters` object. This flaw allows a malicious, unprivileged user to exploit this issue via libvirt\u2019s API virConnectNumOfNWFilters to crash the network filter management daemon (libvirtd/virtnwfilterd).",
"id": "GHSA-4r2g-j5rc-7wqf",
"modified": "2024-04-01T15:30:28Z",
"published": "2022-03-26T00:00:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0897"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2063883"
},
{
"type": "WEB",
"url": "https://gitlab.com/libvirt/libvirt/-/commit/a4947e8f63c3e6b7b067b444f3d6cf674c0d7f36"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00000.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202210-06"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220519-0002"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4R97-P529-3C59
Vulnerability from github – Published: 2022-05-02 03:39 – Updated: 2024-02-15 21:31The kernel in Sun Solaris 8, 9, and 10, and OpenSolaris before snv_103, does not properly handle interaction between the filesystem and virtual-memory implementations, which allows local users to cause a denial of service (deadlock and system halt) via vectors involving mmap and write operations on the same file.
{
"affected": [],
"aliases": [
"CVE-2009-2857"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-08-19T17:30:00Z",
"severity": "MODERATE"
},
"details": "The kernel in Sun Solaris 8, 9, and 10, and OpenSolaris before snv_103, does not properly handle interaction between the filesystem and virtual-memory implementations, which allows local users to cause a denial of service (deadlock and system halt) via vectors involving mmap and write operations on the same file.",
"id": "GHSA-4r97-p529-3c59",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-05-02T03:39:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-2857"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A6152"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/36319"
},
{
"type": "WEB",
"url": "http://sunsolve.sun.com/search/document.do?assetkey=1-21-127721-02-1"
},
{
"type": "WEB",
"url": "http://sunsolve.sun.com/search/document.do?assetkey=1-66-257848-1"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/2291"
}
],
"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-4RM4-8M7J-XWX3
Vulnerability from github – Published: 2022-04-30 18:22 – Updated: 2024-02-08 21:30tip on multiple BSD-based operating systems allows local users to cause a denial of service (execution prevention) by using flock() to lock the /var/log/acculog file.
{
"affected": [],
"aliases": [
"CVE-2002-1915"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2002-12-31T05:00:00Z",
"severity": "LOW"
},
"details": "tip on multiple BSD-based operating systems allows local users to cause a denial of service (execution prevention) by using flock() to lock the /var/log/acculog file.",
"id": "GHSA-4rm4-8m7j-xwx3",
"modified": "2024-02-08T21:30:29Z",
"published": "2022-04-30T18:22:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2002-1915"
},
{
"type": "WEB",
"url": "http://online.securityfocus.com/archive/1/283033"
},
{
"type": "WEB",
"url": "http://www.iss.net/security_center/static/9633.php"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/5265"
}
],
"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-4V29-QMG8-WV42
Vulnerability from github – Published: 2024-08-17 12:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: pdr: protect locator_addr with the main mutex
If the service locator server is restarted fast enough, the PDR can rewrite locator_addr fields concurrently. Protect them by placing modification of those fields under the main pdr->lock.
{
"affected": [],
"aliases": [
"CVE-2024-43849"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-17T10:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: pdr: protect locator_addr with the main mutex\n\nIf the service locator server is restarted fast enough, the PDR can\nrewrite locator_addr fields concurrently. Protect them by placing\nmodification of those fields under the main pdr-\u003elock.",
"id": "GHSA-4v29-qmg8-wv42",
"modified": "2025-11-04T00:31:16Z",
"published": "2024-08-17T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43849"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/107924c14e3ddd85119ca43c26a4ee1056fa9b84"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e815626d73e05152a8142f6e44aecc4133e6e08"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/475a77fb3f0e1d527f56c60b79f5879661df5b80"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8543269567e2fb3d976a8255c5e348aed14f98bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0870c4847e77a49c2f91bb2a8e0fa3c1f8dea5c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eab05737ee22216250fe20d27f5a596da5ea6eb7"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-4VQ6-C2M7-38VX
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
net: bridge: fix soft lockup in br_multicast_query_expired()
When set multicast_query_interval to a large value, the local variable 'time' in br_multicast_send_query() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call mod_timer() again, which creates a loop and may trigger the following soft lockup issue.
watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90
This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 up
The multicast_startup_query_interval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.
{
"affected": [],
"aliases": [
"CVE-2025-39773"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: fix soft lockup in br_multicast_query_expired()\n\nWhen set multicast_query_interval to a large value, the local variable\n\u0027time\u0027 in br_multicast_send_query() may overflow. If the time is smaller\nthan jiffies, the timer will expire immediately, and then call mod_timer()\nagain, which creates a loop and may trigger the following soft lockup\nissue.\n\n watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66]\n CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none)\n Call Trace:\n \u003cIRQ\u003e\n __netdev_alloc_skb+0x2e/0x3a0\n br_ip6_multicast_alloc_query+0x212/0x1b70\n __br_multicast_send_query+0x376/0xac0\n br_multicast_send_query+0x299/0x510\n br_multicast_query_expired.constprop.0+0x16d/0x1b0\n call_timer_fn+0x3b/0x2a0\n __run_timers+0x619/0x950\n run_timer_softirq+0x11c/0x220\n handle_softirqs+0x18e/0x560\n __irq_exit_rcu+0x158/0x1a0\n sysvec_apic_timer_interrupt+0x76/0x90\n \u003c/IRQ\u003e\n\nThis issue can be reproduced with:\n ip link add br0 type bridge\n echo 1 \u003e /sys/class/net/br0/bridge/multicast_querier\n echo 0xffffffffffffffff \u003e\n \t/sys/class/net/br0/bridge/multicast_query_interval\n ip link set dev br0 up\n\nThe multicast_startup_query_interval can also cause this issue. Similar to\nthe commit 99b40610956a (\"net: bridge: mcast: add and enforce query\ninterval minimum\"), add check for the query interval maximum to fix this\nissue.",
"id": "GHSA-4vq6-c2m7-38vx",
"modified": "2026-07-14T15:31:27Z",
"published": "2025-09-11T18:35:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39773"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34171b9e53bd1dc264f5556579f2b04f04435c73"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43e281fde5e76a866a4d10780c35023f16c0e432"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5bf5fce8a0c2a70d063af778fdb5b27238174cdd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96476b043efb86a94f2badd260f7f99c97bd5893"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bdb19cd0de739870bb3494c815138b9dc30875c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d1547bf460baec718b3398365f8de33d25c5f36f"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-5293-CF37-FXQW
Vulnerability from github – Published: 2024-09-13 06:30 – Updated: 2024-09-13 18:31In the Linux kernel, the following vulnerability has been resolved:
firmware: qcom: scm: Mark get_wq_ctx() as atomic call
Currently get_wq_ctx() is wrongly configured as a standard call. When two SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to resume the corresponding sleeping thread. But if get_wq_ctx() is interrupted, goes to sleep and another SMC call is waiting to be allocated a waitq context, it leads to a deadlock.
To avoid this get_wq_ctx() must be an atomic call and can't be a standard SMC call. Hence mark get_wq_ctx() as a fast call.
{
"affected": [],
"aliases": [
"CVE-2024-46692"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-13T06:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: qcom: scm: Mark get_wq_ctx() as atomic call\n\nCurrently get_wq_ctx() is wrongly configured as a standard call. When two\nSMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to\nresume the corresponding sleeping thread. But if get_wq_ctx() is\ninterrupted, goes to sleep and another SMC call is waiting to be allocated\na waitq context, it leads to a deadlock.\n\nTo avoid this get_wq_ctx() must be an atomic call and can\u0027t be a standard\nSMC call. Hence mark get_wq_ctx() as a fast call.",
"id": "GHSA-5293-cf37-fxqw",
"modified": "2024-09-13T18:31:46Z",
"published": "2024-09-13T06:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46692"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9960085a3a82c58d3323c1c20b991db6045063b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cdf7efe4b02aa93813db0bf1ca596ad298ab6b06"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e40115c33c0d79c940545b6b12112aace7acd9f5"
}
],
"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-53CW-7857-2J7G
Vulnerability from github – Published: 2022-05-02 03:30 – Updated: 2024-02-15 21:31The inode double locking code in fs/ocfs2/file.c in the Linux kernel 2.6.30 before 2.6.30-rc3, 2.6.27 before 2.6.27.24, 2.6.29 before 2.6.29.4, and possibly other versions down to 2.6.19 allows local users to cause a denial of service (prevention of file creation and removal) via a series of splice system calls that trigger a deadlock between the generic_file_splice_write, splice_from_pipe, and ocfs2_file_splice_write functions.
{
"affected": [],
"aliases": [
"CVE-2009-1961"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-06-08T01:00:00Z",
"severity": "LOW"
},
"details": "The inode double locking code in fs/ocfs2/file.c in the Linux kernel 2.6.30 before 2.6.30-rc3, 2.6.27 before 2.6.27.24, 2.6.29 before 2.6.29.4, and possibly other versions down to 2.6.19 allows local users to cause a denial of service (prevention of file creation and removal) via a series of splice system calls that trigger a deadlock between the generic_file_splice_write, splice_from_pipe, and ocfs2_file_splice_write functions.",
"id": "GHSA-53cw-7857-2j7g",
"modified": "2024-02-15T21:31:24Z",
"published": "2022-05-02T03:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1961"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commitdiff%3Bh=7bfac9ecf0585962fe13584f5cf526d8c8e76f17"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7bfac9ecf0585962fe13584f5cf526d8c8e76f17"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2009-06/msg00000.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2009-06/msg00001.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2009-07/msg00004.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35390"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35394"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35656"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35847"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/36051"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1022307"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2009/dsa-1844"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDVSA-2009:135"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDVSA-2009:148"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/05/29/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/05/30/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/06/02/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/06/03/1"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2009-1157.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/35143"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/usn-793-1"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-53GX-3HRH-CR29
Vulnerability from github – Published: 2024-02-23 15:30 – Updated: 2024-06-25 21:31In the Linux kernel, the following vulnerability has been resolved:
serial: imx: fix tx statemachine deadlock
When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to drive the RS485 transceiver TX_EN pin. When the TTY port is closed in the middle of a transmission (for instance during userland application crash), imx_uart_shutdown disables the interface and disables the Transmission Complete interrupt. afer that, imx_uart_stop_tx bails on an incomplete transmission, to be retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the interface useless.
imx_uart_stop_tx now checks for incomplete transmission AND whether TC interrupts are enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is properly set to WAIT_AFTER_SEND.
{
"affected": [],
"aliases": [
"CVE-2023-52456"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-23T15:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: imx: fix tx statemachine deadlock\n\nWhen using the serial port as RS485 port, the tx statemachine is used to\ncontrol the RTS pin to drive the RS485 transceiver TX_EN pin. When the\nTTY port is closed in the middle of a transmission (for instance during\nuserland application crash), imx_uart_shutdown disables the interface\nand disables the Transmission Complete interrupt. afer that,\nimx_uart_stop_tx bails on an incomplete transmission, to be retriggered\nby the TC interrupt. This interrupt is disabled and therefore the tx\nstatemachine never transitions out of SEND. The statemachine is in\ndeadlock now, and the TX_EN remains low, making the interface useless.\n\nimx_uart_stop_tx now checks for incomplete transmission AND whether TC\ninterrupts are enabled before bailing to be retriggered. This makes sure\nthe state machine handling is reached, and is properly set to\nWAIT_AFTER_SEND.",
"id": "GHSA-53gx-3hrh-cr29",
"modified": "2024-06-25T21:31:11Z",
"published": "2024-02-23T15:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52456"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00016.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
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.