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.
692 vulnerabilities reference this CWE, most recent first.
GHSA-WH9W-6VGJ-372J
Vulnerability from github – Published: 2024-04-03 15:30 – Updated: 2025-02-03 18:30In the Linux kernel, the following vulnerability has been resolved:
nouveau: offload fence uevents work to workqueue
This should break the deadlock between the fctx lock and the irq lock.
This offloads the processing off the work from the irq into a workqueue.
{
"affected": [],
"aliases": [
"CVE-2024-26719"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T15:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnouveau: offload fence uevents work to workqueue\n\nThis should break the deadlock between the fctx lock and the irq lock.\n\nThis offloads the processing off the work from the irq into a workqueue.",
"id": "GHSA-wh9w-6vgj-372j",
"modified": "2025-02-03T18:30:35Z",
"published": "2024-04-03T15:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26719"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/39126abc5e20611579602f03b66627d7cd1422f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/985d053f7633d8b539ab1531738d538efac678a9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906"
}
],
"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-WHPQ-78MQ-QCJ6
Vulnerability from github – Published: 2023-06-27 21:30 – Updated: 2024-04-04 05:13Xpdf 4.04 will deadlock on a PDF object stream whose "Length" field is itself in another object stream.
{
"affected": [],
"aliases": [
"CVE-2023-3436"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-833"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-27T21:15:16Z",
"severity": "LOW"
},
"details": "Xpdf 4.04 will deadlock on a PDF object stream whose \"Length\" field is itself in another object stream.\n\n",
"id": "GHSA-whpq-78mq-qcj6",
"modified": "2024-04-04T05:13:36Z",
"published": "2023-06-27T21:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3436"
},
{
"type": "WEB",
"url": "https://forum.xpdfreader.com/viewtopic.php?t=42618"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-WHRV-P2HP-QR7F
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-12-23 21:30In the Linux kernel, the following vulnerability has been resolved:
usb: typec: displayport: Fix potential deadlock
The deadlock can occur due to a recursive lock acquisition of
cros_typec_altmode_data::mutex.
The call chain is as follows:
1. cros_typec_altmode_work() acquires the mutex
2. typec_altmode_vdm() -> dp_altmode_vdm() ->
3. typec_altmode_exit() -> cros_typec_altmode_exit()
4. cros_typec_altmode_exit() attempts to acquire the mutex again
To prevent this, defer the typec_altmode_exit() call by scheduling
it rather than calling it directly from within the mutex-protected
context.
{
"affected": [],
"aliases": [
"CVE-2025-38404"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T14:15:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: displayport: Fix potential deadlock\n\nThe deadlock can occur due to a recursive lock acquisition of\n`cros_typec_altmode_data::mutex`.\nThe call chain is as follows:\n1. cros_typec_altmode_work() acquires the mutex\n2. typec_altmode_vdm() -\u003e dp_altmode_vdm() -\u003e\n3. typec_altmode_exit() -\u003e cros_typec_altmode_exit()\n4. cros_typec_altmode_exit() attempts to acquire the mutex again\n\nTo prevent this, defer the `typec_altmode_exit()` call by scheduling\nit rather than calling it directly from within the mutex-protected\ncontext.",
"id": "GHSA-whrv-p2hp-qr7f",
"modified": "2025-12-23T21:30:21Z",
"published": "2025-07-25T15:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38404"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/099cf1fbb8afc3771f408109f62bdec66f85160e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/63cff9f57e86b2dc25d7487ca0118df89a665296"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/749d9076735fb497aae60fbea9fff563f9ea3254"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/76cf1f33e7319fe74c94ac92f9814094ee8cc84b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7be0d1ea71f52595499da39cea484a895e8ed042"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/80c25d7916a44715338d4f8924c8e52af50d0b9f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c782f98eef14197affa8a7b91e6981420f109ea9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb08fca56f1f39e4038cb9bac9864464b13b00aa"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"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-WMJ7-XRRH-R2GJ
Vulnerability from github – Published: 2026-03-04 15:30 – Updated: 2026-03-17 21:31In the Linux kernel, the following vulnerability has been resolved:
Revert "f2fs: block cache/dio write during f2fs_enable_checkpoint()"
This reverts commit 196c81fdd438f7ac429d5639090a9816abb9760a.
Original patch may cause below deadlock, revert it.
write remount - write_begin - lock_page --- lock A - prepare_write_begin - f2fs_map_lock - f2fs_enable_checkpoint - down_write(cp_enable_rwsem) --- lock B - sync_inode_sb - writepages - lock_page --- lock A - down_read(cp_enable_rwsem) --- lock A
{
"affected": [],
"aliases": [
"CVE-2026-23232"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-04T15:16:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"f2fs: block cache/dio write during f2fs_enable_checkpoint()\"\n\nThis reverts commit 196c81fdd438f7ac429d5639090a9816abb9760a.\n\nOriginal patch may cause below deadlock, revert it.\n\nwrite\t\t\t\tremount\n- write_begin\n - lock_page --- lock A\n - prepare_write_begin\n - f2fs_map_lock\n\t\t\t\t- f2fs_enable_checkpoint\n\t\t\t\t - down_write(cp_enable_rwsem) --- lock B\n\t\t\t\t - sync_inode_sb\n\t\t\t\t - writepages\n\t\t\t\t - lock_page\t\t\t--- lock A\n - down_read(cp_enable_rwsem) --- lock A",
"id": "GHSA-wmj7-xrrh-r2gj",
"modified": "2026-03-17T21:31:42Z",
"published": "2026-03-04T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23232"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3996b70209f145bfcf2afc7d05dd92c27b233b48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b6382273801bc7c778545dd8004c9a9d750b4f62"
}
],
"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-WMMX-6X56-W87J
Vulnerability from github – Published: 2024-02-26 18:30 – Updated: 2024-04-17 18:31In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid potential deadlock
Using f2fs_trylock_op() in f2fs_write_compressed_pages() to avoid potential deadlock like we did in f2fs_write_single_data_page().
{
"affected": [],
"aliases": [
"CVE-2020-36775"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-26T18:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid potential deadlock\n\nUsing f2fs_trylock_op() in f2fs_write_compressed_pages() to avoid potential\ndeadlock like we did in f2fs_write_single_data_page().",
"id": "GHSA-wmmx-6x56-w87j",
"modified": "2024-04-17T18:31:31Z",
"published": "2024-02-26T18:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36775"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0478ccdc8ea016de1ebaf6fe6da0275c2b258c5b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8e8542437bb4070423c9754d5ba270ffdbae8c8d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/df77fbd8c5b222c680444801ffd20e8bbc90a56e"
}
],
"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-WP7P-M23W-R9GJ
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-08-29 03:30In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Reload only IB representors upon lag disable/enable
On lag disable, the bond IB device along with all of its representors are destroyed, and then the slaves' representors get reloaded.
In case the slave IB representor load fails, the eswitch error flow unloads all representors, including ethernet representors, where the netdevs get detached and removed from lag bond. Such flow is inaccurate as the lag driver is not responsible for loading/unloading ethernet representors. Furthermore, the flow described above begins by holding lag lock to prevent bond changes during disable flow. However, when reaching the ethernet representors detachment from lag, the lag lock is required again, triggering the following deadlock:
Call trace: __switch_to+0xf4/0x148 __schedule+0x2c8/0x7d0 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x28 __mutex_lock.isra.13+0x2b8/0x570 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x4c/0x68 mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core] mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core] mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core] mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core] mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core] mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core] mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core] mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core] mlx5_disable_lag+0x130/0x138 [mlx5_core] mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev->lock mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core] devlink_nl_cmd_eswitch_set_doit+0xdc/0x180 genl_family_rcv_msg_doit.isra.17+0xe8/0x138 genl_rcv_msg+0xe4/0x220 netlink_rcv_skb+0x44/0x108 genl_rcv+0x40/0x58 netlink_unicast+0x198/0x268 netlink_sendmsg+0x1d4/0x418 sock_sendmsg+0x54/0x60 __sys_sendto+0xf4/0x120 __arm64_sys_sendto+0x30/0x40 el0_svc_common+0x8c/0x120 do_el0_svc+0x30/0xa0 el0_svc+0x20/0x30 el0_sync_handler+0x90/0xb8 el0_sync+0x160/0x180
Thus, upon lag enable/disable, load and unload only the IB representors of the slaves preventing the deadlock mentioned above.
While at it, refactor the mlx5_esw_offloads_rep_load() function to have a static helper method for its internal logic, in symmetry with the representor unload design.
{
"affected": [],
"aliases": [
"CVE-2024-38557"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T14:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Reload only IB representors upon lag disable/enable\n\nOn lag disable, the bond IB device along with all of its\nrepresentors are destroyed, and then the slaves\u0027 representors get reloaded.\n\nIn case the slave IB representor load fails, the eswitch error flow\nunloads all representors, including ethernet representors, where the\nnetdevs get detached and removed from lag bond. Such flow is inaccurate\nas the lag driver is not responsible for loading/unloading ethernet\nrepresentors. Furthermore, the flow described above begins by holding\nlag lock to prevent bond changes during disable flow. However, when\nreaching the ethernet representors detachment from lag, the lag lock is\nrequired again, triggering the following deadlock:\n\nCall trace:\n__switch_to+0xf4/0x148\n__schedule+0x2c8/0x7d0\nschedule+0x50/0xe0\nschedule_preempt_disabled+0x18/0x28\n__mutex_lock.isra.13+0x2b8/0x570\n__mutex_lock_slowpath+0x1c/0x28\nmutex_lock+0x4c/0x68\nmlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core]\nmlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core]\nmlx5e_detach_netdev+0x6c/0xb0 [mlx5_core]\nmlx5e_netdev_change_profile+0x44/0x138 [mlx5_core]\nmlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core]\nmlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core]\nmlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core]\nmlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core]\nmlx5_disable_lag+0x130/0x138 [mlx5_core]\nmlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev-\u003elock\nmlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core]\ndevlink_nl_cmd_eswitch_set_doit+0xdc/0x180\ngenl_family_rcv_msg_doit.isra.17+0xe8/0x138\ngenl_rcv_msg+0xe4/0x220\nnetlink_rcv_skb+0x44/0x108\ngenl_rcv+0x40/0x58\nnetlink_unicast+0x198/0x268\nnetlink_sendmsg+0x1d4/0x418\nsock_sendmsg+0x54/0x60\n__sys_sendto+0xf4/0x120\n__arm64_sys_sendto+0x30/0x40\nel0_svc_common+0x8c/0x120\ndo_el0_svc+0x30/0xa0\nel0_svc+0x20/0x30\nel0_sync_handler+0x90/0xb8\nel0_sync+0x160/0x180\n\nThus, upon lag enable/disable, load and unload only the IB representors\nof the slaves preventing the deadlock mentioned above.\n\nWhile at it, refactor the mlx5_esw_offloads_rep_load() function to have\na static helper method for its internal logic, in symmetry with the\nrepresentor unload design.",
"id": "GHSA-wp7p-m23w-r9gj",
"modified": "2024-08-29T03:30:48Z",
"published": "2024-06-19T15:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38557"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f06228d4a2dcc1fca5b3ddb0eefa09c05b102c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f320f28f54b1b269a755be2e3fb3695e0b80b07"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e93fc8d959e56092e2eca1e5511c2d2f0ad6807a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f03c714a0fdd1f93101a929d0e727c28a66383fc"
}
],
"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-WPWM-R528-7P8J
Vulnerability from github – Published: 2025-03-10 21:31 – Updated: 2025-03-10 21:31In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock
During stress I/O tests with 500+ vports, hard LOCKUP call traces are observed.
CPU A: native_queued_spin_lock_slowpath+0x192 _raw_spin_lock_irqsave+0x32 lpfc_handle_fcp_err+0x4c6 lpfc_fcp_io_cmd_wqe_cmpl+0x964 lpfc_sli4_fp_handle_cqe+0x266 __lpfc_sli4_process_cq+0x105 __lpfc_sli4_hba_process_cq+0x3c lpfc_cq_poll_hdler+0x16 irq_poll_softirq+0x76 __softirqentry_text_start+0xe4 irq_exit+0xf7 do_IRQ+0x7f
CPU B: native_queued_spin_lock_slowpath+0x5b _raw_spin_lock+0x1c lpfc_abort_handler+0x13e scmd_eh_abort_handler+0x85 process_one_work+0x1a7 worker_thread+0x30 kthread+0x112 ret_from_fork+0x1f
Diagram of lockup:
CPUA CPUB ---- ---- lpfc_cmd->buf_lock phba->hbalock lpfc_cmd->buf_lock phba->hbalock
Fix by reordering the taking of the lpfc_cmd->buf_lock and phba->hbalock in lpfc_abort_handler routine so that it tries to take the lpfc_cmd->buf_lock first before phba->hbalock.
{
"affected": [],
"aliases": [
"CVE-2022-49536"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix SCSI I/O completion and abort handler deadlock\n\nDuring stress I/O tests with 500+ vports, hard LOCKUP call traces are\nobserved.\n\nCPU A:\n native_queued_spin_lock_slowpath+0x192\n _raw_spin_lock_irqsave+0x32\n lpfc_handle_fcp_err+0x4c6\n lpfc_fcp_io_cmd_wqe_cmpl+0x964\n lpfc_sli4_fp_handle_cqe+0x266\n __lpfc_sli4_process_cq+0x105\n __lpfc_sli4_hba_process_cq+0x3c\n lpfc_cq_poll_hdler+0x16\n irq_poll_softirq+0x76\n __softirqentry_text_start+0xe4\n irq_exit+0xf7\n do_IRQ+0x7f\n\nCPU B:\n native_queued_spin_lock_slowpath+0x5b\n _raw_spin_lock+0x1c\n lpfc_abort_handler+0x13e\n scmd_eh_abort_handler+0x85\n process_one_work+0x1a7\n worker_thread+0x30\n kthread+0x112\n ret_from_fork+0x1f\n\nDiagram of lockup:\n\nCPUA CPUB\n---- ----\nlpfc_cmd-\u003ebuf_lock\n phba-\u003ehbalock\n lpfc_cmd-\u003ebuf_lock\nphba-\u003ehbalock\n\nFix by reordering the taking of the lpfc_cmd-\u003ebuf_lock and phba-\u003ehbalock in\nlpfc_abort_handler routine so that it tries to take the lpfc_cmd-\u003ebuf_lock\nfirst before phba-\u003ehbalock.",
"id": "GHSA-wpwm-r528-7p8j",
"modified": "2025-03-10T21:31:09Z",
"published": "2025-03-10T21:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49536"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03cbbd7c2f5ee288f648f4aeedc765a181188553"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c4eed901285b9cae36a622f32bea3e92490da6c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/21c0d469349957b5dc811c41200a2a998996ca8d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7625e81de2164a082810e1f27547d388406da610"
}
],
"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-WQF3-H5G7-W9Q8
Vulnerability from github – Published: 2022-04-06 00:01 – Updated: 2022-04-15 00:01Racy interactions between dirty vram tracking and paging log dirty hypercalls Activation of log dirty mode done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while another CPU is still in the process of tearing down the structures related to a previously enabled log dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both operations and can lead to entries being added in already freed slots, resulting in a memory leak.
{
"affected": [],
"aliases": [
"CVE-2022-26356"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-05T13:15:00Z",
"severity": "MODERATE"
},
"details": "Racy interactions between dirty vram tracking and paging log dirty hypercalls Activation of log dirty mode done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while another CPU is still in the process of tearing down the structures related to a previously enabled log dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both operations and can lead to entries being added in already freed slots, resulting in a memory leak.",
"id": "GHSA-wqf3-h5g7-w9q8",
"modified": "2022-04-15T00:01:17Z",
"published": "2022-04-06T00:01:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26356"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6ETPM2OVZZ6KOS2L7QO7SIW6XWT5OW3F"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UHFSRVLM2JUCPDC2KGB7ETPQYJLCGBLD"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6ETPM2OVZZ6KOS2L7QO7SIW6XWT5OW3F"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UHFSRVLM2JUCPDC2KGB7ETPQYJLCGBLD"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202402-07"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5117"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-397.txt"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/04/05/1"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-397.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WRFR-RMR8-J7GX
Vulnerability from github – Published: 2024-06-20 12:31 – Updated: 2024-08-19 18:32In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock between quota disable and qgroup rescan worker
Quota disable ioctl starts a transaction before waiting for the qgroup rescan worker completes. However, this wait can be infinite and results in deadlock because of circular dependency among the quota disable ioctl, the qgroup rescan worker and the other task with transaction such as block group relocation task.
The deadlock happens with the steps following:
1) Task A calls ioctl to disable quota. It starts a transaction and waits for qgroup rescan worker completes. 2) Task B such as block group relocation task starts a transaction and joins to the transaction that task A started. Then task B commits to the transaction. In this commit, task B waits for a commit by task A. 3) Task C as the qgroup rescan worker starts its job and starts a transaction. In this transaction start, task C waits for completion of the transaction that task A started and task B committed.
This deadlock was found with fstests test case btrfs/115 and a zoned null_blk device. The test case enables and disables quota, and the block group reclaim was triggered during the quota disable by chance. The deadlock was also observed by running quota enable and disable in parallel with 'btrfs balance' command on regular null_blk devices.
An example report of the deadlock:
[372.469894] INFO: task kworker/u16:6:103 blocked for more than 122 seconds. [372.479944] Not tainted 5.16.0-rc8 #7 [372.485067] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [372.493898] task:kworker/u16:6 state:D stack: 0 pid: 103 ppid: 2 flags:0x00004000 [372.503285] Workqueue: btrfs-qgroup-rescan btrfs_work_helper [btrfs] [372.510782] Call Trace: [372.514092] [372.521684] __schedule+0xb56/0x4850 [372.530104] ? io_schedule_timeout+0x190/0x190 [372.538842] ? lockdep_hardirqs_on+0x7e/0x100 [372.547092] ? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.555591] schedule+0xe0/0x270 [372.561894] btrfs_commit_transaction+0x18bb/0x2610 [btrfs] [372.570506] ? btrfs_apply_pending_changes+0x50/0x50 [btrfs] [372.578875] ? free_unref_page+0x3f2/0x650 [372.585484] ? finish_wait+0x270/0x270 [372.591594] ? release_extent_buffer+0x224/0x420 [btrfs] [372.599264] btrfs_qgroup_rescan_worker+0xc13/0x10c0 [btrfs] [372.607157] ? lock_release+0x3a9/0x6d0 [372.613054] ? btrfs_qgroup_account_extent+0xda0/0xda0 [btrfs] [372.620960] ? do_raw_spin_lock+0x11e/0x250 [372.627137] ? rwlock_bug.part.0+0x90/0x90 [372.633215] ? lock_is_held_type+0xe4/0x140 [372.639404] btrfs_work_helper+0x1ae/0xa90 [btrfs] [372.646268] process_one_work+0x7e9/0x1320 [372.652321] ? lock_release+0x6d0/0x6d0 [372.658081] ? pwq_dec_nr_in_flight+0x230/0x230 [372.664513] ? rwlock_bug.part.0+0x90/0x90 [372.670529] worker_thread+0x59e/0xf90 [372.676172] ? process_one_work+0x1320/0x1320 [372.682440] kthread+0x3b9/0x490 [372.687550] ? _raw_spin_unlock_irq+0x24/0x50 [372.693811] ? set_kthread_struct+0x100/0x100 [372.700052] ret_from_fork+0x22/0x30 [372.705517] [372.709747] INFO: task btrfs-transacti:2347 blocked for more than 123 seconds. [372.729827] Not tainted 5.16.0-rc8 #7 [372.745907] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [372.767106] task:btrfs-transacti state:D stack: 0 pid: 2347 ppid: 2 flags:0x00004000 [372.787776] Call Trace: [372.801652] [372.812961] __schedule+0xb56/0x4850 [372.830011] ? io_schedule_timeout+0x190/0x190 [372.852547] ? lockdep_hardirqs_on+0x7e/0x100 [372.871761] ? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.886792] schedule+0xe0/0x270 [372.901685] wait_current_trans+0x22c/0x310 [btrfs] [372.919743] ? btrfs_put_transaction+0x3d0/0x3d0 [btrfs] [372.938923] ? finish_wait+0x270/0x270 [372.959085] ? join_transaction+0xc7 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-48734"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-20T12:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock between quota disable and qgroup rescan worker\n\nQuota disable ioctl starts a transaction before waiting for the qgroup\nrescan worker completes. However, this wait can be infinite and results\nin deadlock because of circular dependency among the quota disable\nioctl, the qgroup rescan worker and the other task with transaction such\nas block group relocation task.\n\nThe deadlock happens with the steps following:\n\n1) Task A calls ioctl to disable quota. It starts a transaction and\n waits for qgroup rescan worker completes.\n2) Task B such as block group relocation task starts a transaction and\n joins to the transaction that task A started. Then task B commits to\n the transaction. In this commit, task B waits for a commit by task A.\n3) Task C as the qgroup rescan worker starts its job and starts a\n transaction. In this transaction start, task C waits for completion\n of the transaction that task A started and task B committed.\n\nThis deadlock was found with fstests test case btrfs/115 and a zoned\nnull_blk device. The test case enables and disables quota, and the\nblock group reclaim was triggered during the quota disable by chance.\nThe deadlock was also observed by running quota enable and disable in\nparallel with \u0027btrfs balance\u0027 command on regular null_blk devices.\n\nAn example report of the deadlock:\n\n [372.469894] INFO: task kworker/u16:6:103 blocked for more than 122 seconds.\n [372.479944] Not tainted 5.16.0-rc8 #7\n [372.485067] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n [372.493898] task:kworker/u16:6 state:D stack: 0 pid: 103 ppid: 2 flags:0x00004000\n [372.503285] Workqueue: btrfs-qgroup-rescan btrfs_work_helper [btrfs]\n [372.510782] Call Trace:\n [372.514092] \u003cTASK\u003e\n [372.521684] __schedule+0xb56/0x4850\n [372.530104] ? io_schedule_timeout+0x190/0x190\n [372.538842] ? lockdep_hardirqs_on+0x7e/0x100\n [372.547092] ? _raw_spin_unlock_irqrestore+0x3e/0x60\n [372.555591] schedule+0xe0/0x270\n [372.561894] btrfs_commit_transaction+0x18bb/0x2610 [btrfs]\n [372.570506] ? btrfs_apply_pending_changes+0x50/0x50 [btrfs]\n [372.578875] ? free_unref_page+0x3f2/0x650\n [372.585484] ? finish_wait+0x270/0x270\n [372.591594] ? release_extent_buffer+0x224/0x420 [btrfs]\n [372.599264] btrfs_qgroup_rescan_worker+0xc13/0x10c0 [btrfs]\n [372.607157] ? lock_release+0x3a9/0x6d0\n [372.613054] ? btrfs_qgroup_account_extent+0xda0/0xda0 [btrfs]\n [372.620960] ? do_raw_spin_lock+0x11e/0x250\n [372.627137] ? rwlock_bug.part.0+0x90/0x90\n [372.633215] ? lock_is_held_type+0xe4/0x140\n [372.639404] btrfs_work_helper+0x1ae/0xa90 [btrfs]\n [372.646268] process_one_work+0x7e9/0x1320\n [372.652321] ? lock_release+0x6d0/0x6d0\n [372.658081] ? pwq_dec_nr_in_flight+0x230/0x230\n [372.664513] ? rwlock_bug.part.0+0x90/0x90\n [372.670529] worker_thread+0x59e/0xf90\n [372.676172] ? process_one_work+0x1320/0x1320\n [372.682440] kthread+0x3b9/0x490\n [372.687550] ? _raw_spin_unlock_irq+0x24/0x50\n [372.693811] ? set_kthread_struct+0x100/0x100\n [372.700052] ret_from_fork+0x22/0x30\n [372.705517] \u003c/TASK\u003e\n [372.709747] INFO: task btrfs-transacti:2347 blocked for more than 123 seconds.\n [372.729827] Not tainted 5.16.0-rc8 #7\n [372.745907] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n [372.767106] task:btrfs-transacti state:D stack: 0 pid: 2347 ppid: 2 flags:0x00004000\n [372.787776] Call Trace:\n [372.801652] \u003cTASK\u003e\n [372.812961] __schedule+0xb56/0x4850\n [372.830011] ? io_schedule_timeout+0x190/0x190\n [372.852547] ? lockdep_hardirqs_on+0x7e/0x100\n [372.871761] ? _raw_spin_unlock_irqrestore+0x3e/0x60\n [372.886792] schedule+0xe0/0x270\n [372.901685] wait_current_trans+0x22c/0x310 [btrfs]\n [372.919743] ? btrfs_put_transaction+0x3d0/0x3d0 [btrfs]\n [372.938923] ? finish_wait+0x270/0x270\n [372.959085] ? join_transaction+0xc7\n---truncated---",
"id": "GHSA-wrfr-rmr8-j7gx",
"modified": "2024-08-19T18:32:03Z",
"published": "2024-06-20T12:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48734"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26b3901d20bf9da2c6a00cb1fb48932166f80a45"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/31198e58c09e21d4f65c49d2361f76b87aca4c3f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32747e01436aac8ef93fe85b5b523b4f3b52f040"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89d4cca583fc9594ee7d1a0bc986886d6fb587e6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e804861bd4e69cc5fe1053eedcb024982dde8e48"
}
],
"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-WV5G-RV8W-9X7P
Vulnerability from github – Published: 2024-03-11 18:31 – Updated: 2024-12-12 18:30In the Linux kernel, the following vulnerability has been resolved:
PM: sleep: Fix possible deadlocks in core system-wide PM code
It is reported that in low-memory situations the system-wide resume core code deadlocks, because async_schedule_dev() executes its argument function synchronously if it cannot allocate memory (and not only in that case) and that function attempts to acquire a mutex that is already held. Executing the argument function synchronously from within dpm_async_fn() may also be problematic for ordering reasons (it may cause a consumer device's resume callback to be invoked before a requisite supplier device's one, for example).
Address this by changing the code in question to use async_schedule_dev_nocall() for scheduling the asynchronous execution of device suspend and resume functions and to directly run them synchronously if async_schedule_dev_nocall() returns false.
{
"affected": [],
"aliases": [
"CVE-2023-52498"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-11T18:15:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPM: sleep: Fix possible deadlocks in core system-wide PM code\n\nIt is reported that in low-memory situations the system-wide resume core\ncode deadlocks, because async_schedule_dev() executes its argument\nfunction synchronously if it cannot allocate memory (and not only in\nthat case) and that function attempts to acquire a mutex that is already\nheld. Executing the argument function synchronously from within\ndpm_async_fn() may also be problematic for ordering reasons (it may\ncause a consumer device\u0027s resume callback to be invoked before a\nrequisite supplier device\u0027s one, for example).\n\nAddress this by changing the code in question to use\nasync_schedule_dev_nocall() for scheduling the asynchronous\nexecution of device suspend and resume functions and to directly\nrun them synchronously if async_schedule_dev_nocall() returns false.",
"id": "GHSA-wv5g-rv8w-9x7p",
"modified": "2024-12-12T18:30:50Z",
"published": "2024-03-11T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52498"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.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.