CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
693 vulnerabilities reference this CWE, most recent first.
GHSA-4GQC-44F8-FCVG
Vulnerability from github – Published: 2024-04-17 12:32 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Fix a deadlock issue related to automatic dump
If we issue a disabling PHY command, the device attached with it will go offline, if a 2 bit ECC error occurs at the same time, a hung task may be found:
[ 4613.652388] INFO: task kworker/u256:0:165233 blocked for more than 120 seconds. [ 4613.666297] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4613.674809] task:kworker/u256:0 state:D stack: 0 pid:165233 ppid: 2 flags:0x00000208 [ 4613.683959] Workqueue: 0000:74:02.0_disco_q sas_revalidate_domain [libsas] [ 4613.691518] Call trace: [ 4613.694678] __switch_to+0xf8/0x17c [ 4613.698872] __schedule+0x660/0xee0 [ 4613.703063] schedule+0xac/0x240 [ 4613.706994] schedule_timeout+0x500/0x610 [ 4613.711705] __down+0x128/0x36c [ 4613.715548] down+0x240/0x2d0 [ 4613.719221] hisi_sas_internal_abort_timeout+0x1bc/0x260 [hisi_sas_main] [ 4613.726618] sas_execute_internal_abort+0x144/0x310 [libsas] [ 4613.732976] sas_execute_internal_abort_dev+0x44/0x60 [libsas] [ 4613.739504] hisi_sas_internal_task_abort_dev.isra.0+0xbc/0x1b0 [hisi_sas_main] [ 4613.747499] hisi_sas_dev_gone+0x174/0x250 [hisi_sas_main] [ 4613.753682] sas_notify_lldd_dev_gone+0xec/0x2e0 [libsas] [ 4613.759781] sas_unregister_common_dev+0x4c/0x7a0 [libsas] [ 4613.765962] sas_destruct_devices+0xb8/0x120 [libsas] [ 4613.771709] sas_do_revalidate_domain.constprop.0+0x1b8/0x31c [libsas] [ 4613.778930] sas_revalidate_domain+0x60/0xa4 [libsas] [ 4613.784716] process_one_work+0x248/0x950 [ 4613.789424] worker_thread+0x318/0x934 [ 4613.793878] kthread+0x190/0x200 [ 4613.797810] ret_from_fork+0x10/0x18 [ 4613.802121] INFO: task kworker/u256:4:316722 blocked for more than 120 seconds. [ 4613.816026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4613.824538] task:kworker/u256:4 state:D stack: 0 pid:316722 ppid: 2 flags:0x00000208 [ 4613.833670] Workqueue: 0000:74:02.0 hisi_sas_rst_work_handler [hisi_sas_main] [ 4613.841491] Call trace: [ 4613.844647] __switch_to+0xf8/0x17c [ 4613.848852] __schedule+0x660/0xee0 [ 4613.853052] schedule+0xac/0x240 [ 4613.856984] schedule_timeout+0x500/0x610 [ 4613.861695] __down+0x128/0x36c [ 4613.865542] down+0x240/0x2d0 [ 4613.869216] hisi_sas_controller_prereset+0x58/0x1fc [hisi_sas_main] [ 4613.876324] hisi_sas_rst_work_handler+0x40/0x8c [hisi_sas_main] [ 4613.883019] process_one_work+0x248/0x950 [ 4613.887732] worker_thread+0x318/0x934 [ 4613.892204] kthread+0x190/0x200 [ 4613.896118] ret_from_fork+0x10/0x18 [ 4613.900423] INFO: task kworker/u256:1:348985 blocked for more than 121 seconds. [ 4613.914341] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4613.922852] task:kworker/u256:1 state:D stack: 0 pid:348985 ppid: 2 flags:0x00000208 [ 4613.931984] Workqueue: 0000:74:02.0_event_q sas_port_event_worker [libsas] [ 4613.939549] Call trace: [ 4613.942702] __switch_to+0xf8/0x17c [ 4613.946892] __schedule+0x660/0xee0 [ 4613.951083] schedule+0xac/0x240 [ 4613.955015] schedule_timeout+0x500/0x610 [ 4613.959725] wait_for_common+0x200/0x610 [ 4613.964349] wait_for_completion+0x3c/0x5c [ 4613.969146] flush_workqueue+0x198/0x790 [ 4613.973776] sas_porte_broadcast_rcvd+0x1e8/0x320 [libsas] [ 4613.979960] sas_port_event_worker+0x54/0xa0 [libsas] [ 4613.985708] process_one_work+0x248/0x950 [ 4613.990420] worker_thread+0x318/0x934 [ 4613.994868] kthread+0x190/0x200 [ 4613.998800] ret_from_fork+0x10/0x18
This is because when the device goes offline, we obtain the hisi_hba semaphore and send the ABORT_DEV command to the device. However, the internal abort timed out due to the 2 bit ECC error and triggers automatic dump. In addition, since the hisi_hba semaphore has been obtained, the dump cannot be executed and the controller cannot be reset.
Therefore, the deadlocks occur on the following circular dependencies ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26873"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T11:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Fix a deadlock issue related to automatic dump\n\nIf we issue a disabling PHY command, the device attached with it will go\noffline, if a 2 bit ECC error occurs at the same time, a hung task may be\nfound:\n\n[ 4613.652388] INFO: task kworker/u256:0:165233 blocked for more than 120 seconds.\n[ 4613.666297] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 4613.674809] task:kworker/u256:0 state:D stack: 0 pid:165233 ppid: 2 flags:0x00000208\n[ 4613.683959] Workqueue: 0000:74:02.0_disco_q sas_revalidate_domain [libsas]\n[ 4613.691518] Call trace:\n[ 4613.694678] __switch_to+0xf8/0x17c\n[ 4613.698872] __schedule+0x660/0xee0\n[ 4613.703063] schedule+0xac/0x240\n[ 4613.706994] schedule_timeout+0x500/0x610\n[ 4613.711705] __down+0x128/0x36c\n[ 4613.715548] down+0x240/0x2d0\n[ 4613.719221] hisi_sas_internal_abort_timeout+0x1bc/0x260 [hisi_sas_main]\n[ 4613.726618] sas_execute_internal_abort+0x144/0x310 [libsas]\n[ 4613.732976] sas_execute_internal_abort_dev+0x44/0x60 [libsas]\n[ 4613.739504] hisi_sas_internal_task_abort_dev.isra.0+0xbc/0x1b0 [hisi_sas_main]\n[ 4613.747499] hisi_sas_dev_gone+0x174/0x250 [hisi_sas_main]\n[ 4613.753682] sas_notify_lldd_dev_gone+0xec/0x2e0 [libsas]\n[ 4613.759781] sas_unregister_common_dev+0x4c/0x7a0 [libsas]\n[ 4613.765962] sas_destruct_devices+0xb8/0x120 [libsas]\n[ 4613.771709] sas_do_revalidate_domain.constprop.0+0x1b8/0x31c [libsas]\n[ 4613.778930] sas_revalidate_domain+0x60/0xa4 [libsas]\n[ 4613.784716] process_one_work+0x248/0x950\n[ 4613.789424] worker_thread+0x318/0x934\n[ 4613.793878] kthread+0x190/0x200\n[ 4613.797810] ret_from_fork+0x10/0x18\n[ 4613.802121] INFO: task kworker/u256:4:316722 blocked for more than 120 seconds.\n[ 4613.816026] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 4613.824538] task:kworker/u256:4 state:D stack: 0 pid:316722 ppid: 2 flags:0x00000208\n[ 4613.833670] Workqueue: 0000:74:02.0 hisi_sas_rst_work_handler [hisi_sas_main]\n[ 4613.841491] Call trace:\n[ 4613.844647] __switch_to+0xf8/0x17c\n[ 4613.848852] __schedule+0x660/0xee0\n[ 4613.853052] schedule+0xac/0x240\n[ 4613.856984] schedule_timeout+0x500/0x610\n[ 4613.861695] __down+0x128/0x36c\n[ 4613.865542] down+0x240/0x2d0\n[ 4613.869216] hisi_sas_controller_prereset+0x58/0x1fc [hisi_sas_main]\n[ 4613.876324] hisi_sas_rst_work_handler+0x40/0x8c [hisi_sas_main]\n[ 4613.883019] process_one_work+0x248/0x950\n[ 4613.887732] worker_thread+0x318/0x934\n[ 4613.892204] kthread+0x190/0x200\n[ 4613.896118] ret_from_fork+0x10/0x18\n[ 4613.900423] INFO: task kworker/u256:1:348985 blocked for more than 121 seconds.\n[ 4613.914341] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 4613.922852] task:kworker/u256:1 state:D stack: 0 pid:348985 ppid: 2 flags:0x00000208\n[ 4613.931984] Workqueue: 0000:74:02.0_event_q sas_port_event_worker [libsas]\n[ 4613.939549] Call trace:\n[ 4613.942702] __switch_to+0xf8/0x17c\n[ 4613.946892] __schedule+0x660/0xee0\n[ 4613.951083] schedule+0xac/0x240\n[ 4613.955015] schedule_timeout+0x500/0x610\n[ 4613.959725] wait_for_common+0x200/0x610\n[ 4613.964349] wait_for_completion+0x3c/0x5c\n[ 4613.969146] flush_workqueue+0x198/0x790\n[ 4613.973776] sas_porte_broadcast_rcvd+0x1e8/0x320 [libsas]\n[ 4613.979960] sas_port_event_worker+0x54/0xa0 [libsas]\n[ 4613.985708] process_one_work+0x248/0x950\n[ 4613.990420] worker_thread+0x318/0x934\n[ 4613.994868] kthread+0x190/0x200\n[ 4613.998800] ret_from_fork+0x10/0x18\n\nThis is because when the device goes offline, we obtain the hisi_hba\nsemaphore and send the ABORT_DEV command to the device. However, the\ninternal abort timed out due to the 2 bit ECC error and triggers automatic\ndump. In addition, since the hisi_hba semaphore has been obtained, the dump\ncannot be executed and the controller cannot be reset.\n\nTherefore, the deadlocks occur on the following circular dependencies\n---truncated---",
"id": "GHSA-4gqc-44f8-fcvg",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-04-17T12:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26873"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c4f53b2c341ec6428b98cb51a89a09b025d0953"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85c98073ffcfe9e46abfb9c66f3364467119d563"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a47f0b03149af538af4442ff0702eac430ace1cb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e022dd3b875315a2d2001a512e98d1dc8c991f4a"
}
],
"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-4J23-W98Q-23FX
Vulnerability from github – Published: 2025-10-23 12:31 – Updated: 2025-10-23 12:31In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Fix sleep from invalid context BUG
Taking the qos_mutex to process RoCEv2 QP's on netdev events causes a kernel splat.
Fix this by removing the handling for RoCEv2 in irdma_cm_teardown_connections that uses the mutex. This handling is only needed for iWARP to avoid having connections established while the link is down or having connections remain functional after the IP address is removed.
BUG: sleeping function called from invalid context at kernel/locking/mutex. Call Trace: kernel: dump_stack+0x66/0x90 kernel: mightsleep.cold.92+0x8d/0x9a kernel: mutex_lock+0x1c/0x40 kernel: irdma_cm_teardown_connections+0x28e/0x4d0 [irdma] kernel: ? check_preempt_curr+0x7a/0x90 kernel: ? select_idle_sibling+0x22/0x3c0 kernel: ? select_task_rq_fair+0x94c/0xc90 kernel: ? irdma_exec_cqp_cmd+0xc27/0x17c0 [irdma] kernel: ? wake_up_common+0x7a/0x190 kernel: irdma_if_notify+0x3cc/0x450 [irdma] kernel: ? sched_clock_cpu+0xc/0xb0 kernel: irdma_inet6addr_event+0xc6/0x150 [irdma]
{
"affected": [],
"aliases": [
"CVE-2022-49606"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:36Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/irdma: Fix sleep from invalid context BUG\n\nTaking the qos_mutex to process RoCEv2 QP\u0027s on netdev events causes a\nkernel splat.\n\nFix this by removing the handling for RoCEv2 in\nirdma_cm_teardown_connections that uses the mutex. This handling is only\nneeded for iWARP to avoid having connections established while the link is\ndown or having connections remain functional after the IP address is\nremoved.\n\n BUG: sleeping function called from invalid context at kernel/locking/mutex.\n Call Trace:\n kernel: dump_stack+0x66/0x90\n kernel: ___might_sleep.cold.92+0x8d/0x9a\n kernel: mutex_lock+0x1c/0x40\n kernel: irdma_cm_teardown_connections+0x28e/0x4d0 [irdma]\n kernel: ? check_preempt_curr+0x7a/0x90\n kernel: ? select_idle_sibling+0x22/0x3c0\n kernel: ? select_task_rq_fair+0x94c/0xc90\n kernel: ? irdma_exec_cqp_cmd+0xc27/0x17c0 [irdma]\n kernel: ? __wake_up_common+0x7a/0x190\n kernel: irdma_if_notify+0x3cc/0x450 [irdma]\n kernel: ? sched_clock_cpu+0xc/0xb0\n kernel: irdma_inet6addr_event+0xc6/0x150 [irdma]",
"id": "GHSA-4j23-w98q-23fx",
"modified": "2025-10-23T12:31:15Z",
"published": "2025-10-23T12:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49606"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cae7e519032e4b4672cb9204d5586a441924364"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4c5115140ed1833197bad9a6b80265840ff427f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc0315564d6eec91c716d314b743321be24c70b3"
}
],
"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-4JR3-HWQP-2VQ3
Vulnerability from github – Published: 2024-03-03 00:30 – Updated: 2024-12-11 18:30In the Linux kernel, the following vulnerability has been resolved:
dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock
__dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock.
Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we don't acquire serial console's port->lock under it.
Trimmed-down lockdep splat:
The existing dependency chain (in reverse order) is:
-> #2 (free_entries_lock){-.-.}-{2:2}:
_raw_spin_lock_irqsave+0x60/0x80
dma_entry_alloc+0x38/0x110
debug_dma_map_page+0x60/0xf8
dma_map_page_attrs+0x1e0/0x230
dma_map_single_attrs.constprop.0+0x6c/0xc8
geni_se_rx_dma_prep+0x40/0xcc
qcom_geni_serial_isr+0x310/0x510
__handle_irq_event_percpu+0x110/0x244
handle_irq_event_percpu+0x20/0x54
handle_irq_event+0x50/0x88
handle_fasteoi_irq+0xa4/0xcc
handle_irq_desc+0x28/0x40
generic_handle_domain_irq+0x24/0x30
gic_handle_irq+0xc4/0x148
do_interrupt_handler+0xa4/0xb0
el1_interrupt+0x34/0x64
el1h_64_irq_handler+0x18/0x24
el1h_64_irq+0x64/0x68
arch_local_irq_enable+0x4/0x8
____do_softirq+0x18/0x24
...
-> #1 (&port_lock_key){-.-.}-{2:2}:
_raw_spin_lock_irqsave+0x60/0x80
qcom_geni_serial_console_write+0x184/0x1dc
console_flush_all+0x344/0x454
console_unlock+0x94/0xf0
vprintk_emit+0x238/0x24c
vprintk_default+0x3c/0x48
vprintk+0xb4/0xbc
_printk+0x68/0x90
register_console+0x230/0x38c
uart_add_one_port+0x338/0x494
qcom_geni_serial_probe+0x390/0x424
platform_probe+0x70/0xc0
really_probe+0x148/0x280
__driver_probe_device+0xfc/0x114
driver_probe_device+0x44/0x100
__device_attach_driver+0x64/0xdc
bus_for_each_drv+0xb0/0xd8
__device_attach+0xe4/0x140
device_initial_probe+0x1c/0x28
bus_probe_device+0x44/0xb0
device_add+0x538/0x668
of_device_add+0x44/0x50
of_platform_device_create_pdata+0x94/0xc8
of_platform_bus_create+0x270/0x304
of_platform_populate+0xac/0xc4
devm_of_platform_populate+0x60/0xac
geni_se_probe+0x154/0x160
platform_probe+0x70/0xc0
...
-> #0 (console_owner){-...}-{0:0}:
__lock_acquire+0xdf8/0x109c
lock_acquire+0x234/0x284
console_flush_all+0x330/0x454
console_unlock+0x94/0xf0
vprintk_emit+0x238/0x24c
vprintk_default+0x3c/0x48
vprintk+0xb4/0xbc
_printk+0x68/0x90
dma_entry_alloc+0xb4/0x110
debug_dma_map_sg+0xdc/0x2f8
__dma_map_sg_attrs+0xac/0xe4
dma_map_sgtable+0x30/0x4c
get_pages+0x1d4/0x1e4 [msm]
msm_gem_pin_pages_locked+0x38/0xac [msm]
msm_gem_pin_vma_locked+0x58/0x88 [msm]
msm_ioctl_gem_submit+0xde4/0x13ac [msm]
drm_ioctl_kernel+0xe0/0x15c
drm_ioctl+0x2e8/0x3f4
vfs_ioctl+0x30/0x50
...
Chain exists of: console_owner --> &port_lock_key --> free_entries_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(free_entries_lock); lock(&port_lock_key); lock(free_entries_lock); lock(console_owner);
*** DEADLOCK ***
Call trace: dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-52516"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-02T22:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndma-debug: don\u0027t call __dma_entry_alloc_check_leak() under free_entries_lock\n\n__dma_entry_alloc_check_leak() calls into printk -\u003e serial console\noutput (qcom geni) and grabs port-\u003elock under free_entries_lock\nspin lock, which is a reverse locking dependency chain as qcom_geni\nIRQ handler can call into dma-debug code and grab free_entries_lock\nunder port-\u003elock.\n\nMove __dma_entry_alloc_check_leak() call out of free_entries_lock\nscope so that we don\u0027t acquire serial console\u0027s port-\u003elock under it.\n\nTrimmed-down lockdep splat:\n\n The existing dependency chain (in reverse order) is:\n\n -\u003e #2 (free_entries_lock){-.-.}-{2:2}:\n _raw_spin_lock_irqsave+0x60/0x80\n dma_entry_alloc+0x38/0x110\n debug_dma_map_page+0x60/0xf8\n dma_map_page_attrs+0x1e0/0x230\n dma_map_single_attrs.constprop.0+0x6c/0xc8\n geni_se_rx_dma_prep+0x40/0xcc\n qcom_geni_serial_isr+0x310/0x510\n __handle_irq_event_percpu+0x110/0x244\n handle_irq_event_percpu+0x20/0x54\n handle_irq_event+0x50/0x88\n handle_fasteoi_irq+0xa4/0xcc\n handle_irq_desc+0x28/0x40\n generic_handle_domain_irq+0x24/0x30\n gic_handle_irq+0xc4/0x148\n do_interrupt_handler+0xa4/0xb0\n el1_interrupt+0x34/0x64\n el1h_64_irq_handler+0x18/0x24\n el1h_64_irq+0x64/0x68\n arch_local_irq_enable+0x4/0x8\n ____do_softirq+0x18/0x24\n ...\n\n -\u003e #1 (\u0026port_lock_key){-.-.}-{2:2}:\n _raw_spin_lock_irqsave+0x60/0x80\n qcom_geni_serial_console_write+0x184/0x1dc\n console_flush_all+0x344/0x454\n console_unlock+0x94/0xf0\n vprintk_emit+0x238/0x24c\n vprintk_default+0x3c/0x48\n vprintk+0xb4/0xbc\n _printk+0x68/0x90\n register_console+0x230/0x38c\n uart_add_one_port+0x338/0x494\n qcom_geni_serial_probe+0x390/0x424\n platform_probe+0x70/0xc0\n really_probe+0x148/0x280\n __driver_probe_device+0xfc/0x114\n driver_probe_device+0x44/0x100\n __device_attach_driver+0x64/0xdc\n bus_for_each_drv+0xb0/0xd8\n __device_attach+0xe4/0x140\n device_initial_probe+0x1c/0x28\n bus_probe_device+0x44/0xb0\n device_add+0x538/0x668\n of_device_add+0x44/0x50\n of_platform_device_create_pdata+0x94/0xc8\n of_platform_bus_create+0x270/0x304\n of_platform_populate+0xac/0xc4\n devm_of_platform_populate+0x60/0xac\n geni_se_probe+0x154/0x160\n platform_probe+0x70/0xc0\n ...\n\n -\u003e #0 (console_owner){-...}-{0:0}:\n __lock_acquire+0xdf8/0x109c\n lock_acquire+0x234/0x284\n console_flush_all+0x330/0x454\n console_unlock+0x94/0xf0\n vprintk_emit+0x238/0x24c\n vprintk_default+0x3c/0x48\n vprintk+0xb4/0xbc\n _printk+0x68/0x90\n dma_entry_alloc+0xb4/0x110\n debug_dma_map_sg+0xdc/0x2f8\n __dma_map_sg_attrs+0xac/0xe4\n dma_map_sgtable+0x30/0x4c\n get_pages+0x1d4/0x1e4 [msm]\n msm_gem_pin_pages_locked+0x38/0xac [msm]\n msm_gem_pin_vma_locked+0x58/0x88 [msm]\n msm_ioctl_gem_submit+0xde4/0x13ac [msm]\n drm_ioctl_kernel+0xe0/0x15c\n drm_ioctl+0x2e8/0x3f4\n vfs_ioctl+0x30/0x50\n ...\n\n Chain exists of:\n console_owner --\u003e \u0026port_lock_key --\u003e free_entries_lock\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(free_entries_lock);\n lock(\u0026port_lock_key);\n lock(free_entries_lock);\n lock(console_owner);\n\n *** DEADLOCK ***\n\n Call trace:\n dump_backtrace+0xb4/0xf0\n show_stack+0x20/0x30\n dump_stack_lvl+0x60/0x84\n dump_stack+0x18/0x24\n print_circular_bug+0x1cc/0x234\n check_noncircular+0x78/0xac\n __lock_acquire+0xdf8/0x109c\n lock_acquire+0x234/0x284\n console_flush_all+0x330/0x454\n consol\n---truncated---",
"id": "GHSA-4jr3-hwqp-2vq3",
"modified": "2024-12-11T18:30:36Z",
"published": "2024-03-03T00:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52516"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac0d068099349cbca3d93f2e3b15bb329364b08c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be8f49029eca3efbad0d74dbff3cb9129994ffab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c79300599923daaa30f417c75555d5566b3d31ae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fb5a4315591dae307a65fc246ca80b5159d296e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe2b811a02c3244ebf6059039e4a9e715e26a9e3"
}
],
"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-4Q76-CFMR-JQCP
Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2022-05-24 16:58An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges by leveraging incorrect use of the HVM physmap concept for PV domains.
{
"affected": [],
"aliases": [
"CVE-2019-17343"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-08T01:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges by leveraging incorrect use of the HVM physmap concept for PV domains.",
"id": "GHSA-4q76-cfmr-jqcp",
"modified": "2022-05-24T16:58:09Z",
"published": "2022-05-24T16:58:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17343"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2020/Jan/21"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4602"
},
{
"type": "WEB",
"url": "https://xenbits.xen.org/xsa/advisory-288.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/10/25/10"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-288.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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"
}
]
}
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.