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.
705 vulnerabilities reference this CWE, most recent first.
GHSA-XW4W-P39H-FRX8
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2025-09-22 21:30In the Linux kernel, the following vulnerability has been resolved:
ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
When user_dlm_destroy_lock failed, it didn't clean up the flags it set before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of lock is still in used, next time when unlink invokes this function, it will return succeed, and then unlink will remove inode and dentry if lock is not in used(file closed), but the dlm lock is still linked in dlm lock resource, then when bast come in, it will trigger a panic due to user-after-free. See the following panic call trace. To fix this, USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink fail.
For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN, USER_LOCK_BUSY is also required to be cleared. Even though spin lock is released in between, but USER_LOCK_IN_TEARDOWN is still set, for USER_LOCK_BUSY, if before every place that waits on this flag, USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow waits on the busy flag set by user_dlm_destroy_lock(), then we can simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix user_dlm_cluster_lock() which is the only function not following this.
[ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink 004fb0000060000b5a90b8c847b72e1, error -16 from destroy [ 989.757536] ------------[ cut here ]------------ [ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173! [ 989.757876] invalid opcode: 0000 [#1] SMP [ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O) ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5 auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE) mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si ipmi_msghandler [ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ksplice_2zhuk2jr_ib_ipoib_old] [ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE 4.1.12-124.57.1.el6uek.x86_64 #2 [ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021 [ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti: ffff88017f7c8000 [ 989.762848] RIP: e030:[] [] __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs] [ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246 [ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX: 0000000000000003 [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI: ffff880174d48170 [ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09: 0000000000000000 [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12: ffff880174d48008 [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15: ffff88021db7a000 [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000) knlGS:ffff880247480000 [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4: 0000000000042660 [ 989.765081] Stack: [ 989.765167] 00000000000 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-49337"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: dlmfs: fix error handling of user_dlm_destroy_lock\n\nWhen user_dlm_destroy_lock failed, it didn\u0027t clean up the flags it set\nbefore exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of\nlock is still in used, next time when unlink invokes this function, it\nwill return succeed, and then unlink will remove inode and dentry if lock\nis not in used(file closed), but the dlm lock is still linked in dlm lock\nresource, then when bast come in, it will trigger a panic due to\nuser-after-free. See the following panic call trace. To fix this,\nUSER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should\nbe returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink\nfail.\n\nFor the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN,\nUSER_LOCK_BUSY is also required to be cleared. Even though spin lock is\nreleased in between, but USER_LOCK_IN_TEARDOWN is still set, for\nUSER_LOCK_BUSY, if before every place that waits on this flag,\nUSER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow\nwaits on the busy flag set by user_dlm_destroy_lock(), then we can\nsimplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix\nuser_dlm_cluster_lock() which is the only function not following this.\n\n[ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink\n004fb0000060000b5a90b8c847b72e1, error -16 from destroy\n[ 989.757536] ------------[ cut here ]------------\n[ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173!\n[ 989.757876] invalid opcode: 0000 [#1] SMP\n[ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O)\nksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc\nxen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5\nauth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs\nocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc\nfcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc\nrds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad\nrdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE)\nmlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad\nib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support\npcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si\nipmi_msghandler\n[ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp\npps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel\nbe2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio\nlibiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi\ndm_mirror dm_region_hash dm_log dm_mod [last unloaded:\nksplice_2zhuk2jr_ib_ipoib_old]\n[ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE\n4.1.12-124.57.1.el6uek.x86_64 #2\n[ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER\nX5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021\n[ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti:\nffff88017f7c8000\n[ 989.762848] RIP: e030:[\u003cffffffffc07d4316\u003e] [\u003cffffffffc07d4316\u003e]\n__user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs]\n[ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246\n[ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX:\n0000000000000003\n[ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI:\nffff880174d48170\n[ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09:\n0000000000000000\n[ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12:\nffff880174d48008\n[ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15:\nffff88021db7a000\n[ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000)\nknlGS:ffff880247480000\n[ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4:\n0000000000042660\n[ 989.765081] Stack:\n[ 989.765167] 00000000000\n---truncated---",
"id": "GHSA-xw4w-p39h-frx8",
"modified": "2025-09-22T21:30:16Z",
"published": "2025-09-22T21:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49337"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/02480e2e82ae0e5588374bbbcf4fa6e4959fa174"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1434cd71ad9f3a6beda3036972983b6c4869207c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2c5e26a626fe46675bceba853e12aaf13c712e10"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/337e36550788dbe03254f0593a231c1c4873b20d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/733a35c00ef363a1c774d7ea486e0735b7c13a15"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82bf8e7271fade40184177cb406203addc34c4a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/863e0d81b6683c4cbc588ad831f560c90e494bef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c96238fac045b289993d7bc5aae7b2d72b25c76"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/efb54ec548829e1d3605f0434526f86e345b1b28"
}
],
"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-XW74-3HJF-3XPV
Vulnerability from github – Published: 2025-12-22 18:30 – Updated: 2026-02-26 18:31In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Fix possible deadlock in the deferred_irq_workfn()
For PREEMPT_RT=y kernels, the deferred_irq_workfn() is executed in the per-cpu irq_work/* task context and not disable-irq, if the rq returned by container_of() is current CPU's rq, the following scenarios may occur:
lock(&rq->__lock); lock(&rq->__lock);
This commit use IRQ_WORK_INIT_HARD() to replace init_irq_work() to initialize rq->scx.deferred_irq_work, make the deferred_irq_workfn() is always invoked in hard-irq context.
{
"affected": [],
"aliases": [
"CVE-2025-68333"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-22T17:16:01Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Fix possible deadlock in the deferred_irq_workfn()\n\nFor PREEMPT_RT=y kernels, the deferred_irq_workfn() is executed in\nthe per-cpu irq_work/* task context and not disable-irq, if the rq\nreturned by container_of() is current CPU\u0027s rq, the following scenarios\nmay occur:\n\nlock(\u0026rq-\u003e__lock);\n\u003cInterrupt\u003e\n lock(\u0026rq-\u003e__lock);\n\nThis commit use IRQ_WORK_INIT_HARD() to replace init_irq_work() to\ninitialize rq-\u003escx.deferred_irq_work, make the deferred_irq_workfn()\nis always invoked in hard-irq context.",
"id": "GHSA-xw74-3hjf-3xpv",
"modified": "2026-02-26T18:31:34Z",
"published": "2025-12-22T18:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68333"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/541959b2fadb832a7d0ceb95041dc52bdcf6bff7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/600b4379b9a7ba41340d652211fb29699da4c629"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a257e974210320ede524f340ffe16bf4bf0dda1e"
}
],
"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-XWG7-JQ5F-XFCJ
Vulnerability from github – Published: 2022-06-16 00:00 – Updated: 2022-06-29 00:00Improper Resource Locking vulnerability in Mitsubishi Electric MELSEC-Q Series Q03UDECPU all versions, Mitsubishi Electric MELSEC-Q Series Q04/06/10/13/20/26/50/100UDEHCPU all versions, Mitsubishi Electric MELSEC-Q Series Q03/04/06/13/26UDVCPU the first 5 digits of serial number "24051" and prior, Mitsubishi Electric MELSEC-Q Series Q04/06/13/26UDPVCPU the first 5 digits of serial number "24051" and prior, Mitsubishi Electric MELSEC-L series L02/06/26CPU(-P) the first 5 digits of serial number "24051" and prior and Mitsubishi Electric MELSEC-L series L26CPU-(P)BT the first 5 digits of serial number "24051" and prior allows a remote unauthenticated attacker to cause a denial of service (DoS) condition in Ethernet communications by sending specially crafted packets. A system reset of the products is required for recovery.
{
"affected": [],
"aliases": [
"CVE-2022-24946"
],
"database_specific": {
"cwe_ids": [
"CWE-413",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-15T21:15:00Z",
"severity": "HIGH"
},
"details": "Improper Resource Locking vulnerability in Mitsubishi Electric MELSEC-Q Series Q03UDECPU all versions, Mitsubishi Electric MELSEC-Q Series Q04/06/10/13/20/26/50/100UDEHCPU all versions, Mitsubishi Electric MELSEC-Q Series Q03/04/06/13/26UDVCPU the first 5 digits of serial number \"24051\" and prior, Mitsubishi Electric MELSEC-Q Series Q04/06/13/26UDPVCPU the first 5 digits of serial number \"24051\" and prior, Mitsubishi Electric MELSEC-L series L02/06/26CPU(-P) the first 5 digits of serial number \"24051\" and prior and Mitsubishi Electric MELSEC-L series L26CPU-(P)BT the first 5 digits of serial number \"24051\" and prior allows a remote unauthenticated attacker to cause a denial of service (DoS) condition in Ethernet communications by sending specially crafted packets. A system reset of the products is required for recovery.",
"id": "GHSA-xwg7-jq5f-xfcj",
"modified": "2022-06-29T00:00:29Z",
"published": "2022-06-16T00:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24946"
},
{
"type": "WEB",
"url": "https://jvn.jp/vu/JVNVU#90895626/index.html"
},
{
"type": "WEB",
"url": "https://jvn.jp/vu/JVNVU90895626/index.html"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-172-01"
},
{
"type": "WEB",
"url": "https://www.mitsubishielectric.com/en/psirt/vulnerability/pdf/2022-007_en.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XX3R-74M7-RJG4
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-09-19 18:31In the Linux kernel, the following vulnerability has been resolved:
md/dm-raid: don't call md_reap_sync_thread() directly
Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'.
However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock").
Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did.
{
"affected": [],
"aliases": [
"CVE-2024-35808"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd/dm-raid: don\u0027t call md_reap_sync_thread() directly\n\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0027reconfig_mutex\u0027, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0027reconfig_mutex\u0027.\n\nHowever, hold \u0027reconfig_mutex\u0027 here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\"md: refactor\nidle/frozen_sync_thread() to fix deadlock\").\n\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did.",
"id": "GHSA-xx3r-74m7-rjg4",
"modified": "2025-09-19T18:31:17Z",
"published": "2024-05-17T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35808"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/347dcdc15a1706f61aa545ae498ededdf31aeebc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e59b8d76ff511505eb0dd1478329f09e0f04669"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd32b27a66db8776d8b8e82ec7d7dde97a8693b0"
}
],
"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-XXMG-RP7C-344J
Vulnerability from github – Published: 2024-08-17 09:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
Revert "ALSA: firewire-lib: operate for period elapse event in process context"
Commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period elapse event in process context") removed the process context workqueue from amdtp_domain_stream_pcm_pointer() and update_pcm_pointers() to remove its overhead.
With RME Fireface 800, this lead to a regression since Kernels 5.14.0, causing an AB/BA deadlock competition for the substream lock with eventual system freeze under ALSA operation:
thread 0: * (lock A) acquire substream lock by snd_pcm_stream_lock_irq() in snd_pcm_status64() * (lock B) wait for tasklet to finish by calling tasklet_unlock_spin_wait() in tasklet_disable_in_atomic() in ohci_flush_iso_completions() of ohci.c
thread 1: * (lock B) enter tasklet * (lock A) attempt to acquire substream lock, waiting for it to be released: snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed() in update_pcm_pointers() in process_ctx_payloads() in process_rx_packets() of amdtp-stream.c
? tasklet_unlock_spin_wait ohci_flush_iso_completions firewire_ohci amdtp_domain_stream_pcm_pointer snd_firewire_lib snd_pcm_update_hw_ptr0 snd_pcm snd_pcm_status64 snd_pcm
? native_queued_spin_lock_slowpath _raw_spin_lock_irqsave snd_pcm_period_elapsed snd_pcm process_rx_packets snd_firewire_lib irq_target_callback snd_firewire_lib handle_it_packet firewire_ohci context_tasklet firewire_ohci
Restore the process context work queue to prevent deadlock AB/BA deadlock competition for ALSA substream lock of snd_pcm_stream_lock_irq() in snd_pcm_status64() and snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed().
revert commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period elapse event in process context")
Replace inline description to prevent future deadlock.
{
"affected": [],
"aliases": [
"CVE-2024-42274"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-17T09:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"ALSA: firewire-lib: operate for period elapse event in process context\"\n\nCommit 7ba5ca32fe6e (\"ALSA: firewire-lib: operate for period elapse event\nin process context\") removed the process context workqueue from\namdtp_domain_stream_pcm_pointer() and update_pcm_pointers() to remove\nits overhead.\n\nWith RME Fireface 800, this lead to a regression since\nKernels 5.14.0, causing an AB/BA deadlock competition for the\nsubstream lock with eventual system freeze under ALSA operation:\n\nthread 0:\n * (lock A) acquire substream lock by\n\tsnd_pcm_stream_lock_irq() in\n\tsnd_pcm_status64()\n * (lock B) wait for tasklet to finish by calling\n \ttasklet_unlock_spin_wait() in\n\ttasklet_disable_in_atomic() in\n\tohci_flush_iso_completions() of ohci.c\n\nthread 1:\n * (lock B) enter tasklet\n * (lock A) attempt to acquire substream lock,\n \twaiting for it to be released:\n\tsnd_pcm_stream_lock_irqsave() in\n \tsnd_pcm_period_elapsed() in\n\tupdate_pcm_pointers() in\n\tprocess_ctx_payloads() in\n\tprocess_rx_packets() of amdtp-stream.c\n\n? tasklet_unlock_spin_wait\n \u003c/NMI\u003e\n \u003cTASK\u003e\nohci_flush_iso_completions firewire_ohci\namdtp_domain_stream_pcm_pointer snd_firewire_lib\nsnd_pcm_update_hw_ptr0 snd_pcm\nsnd_pcm_status64 snd_pcm\n\n? native_queued_spin_lock_slowpath\n \u003c/NMI\u003e\n \u003cIRQ\u003e\n_raw_spin_lock_irqsave\nsnd_pcm_period_elapsed snd_pcm\nprocess_rx_packets snd_firewire_lib\nirq_target_callback snd_firewire_lib\nhandle_it_packet firewire_ohci\ncontext_tasklet firewire_ohci\n\nRestore the process context work queue to prevent deadlock\nAB/BA deadlock competition for ALSA substream lock of\nsnd_pcm_stream_lock_irq() in snd_pcm_status64()\nand snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed().\n\nrevert commit 7ba5ca32fe6e (\"ALSA: firewire-lib: operate for period\nelapse event in process context\")\n\nReplace inline description to prevent future deadlock.",
"id": "GHSA-xxmg-rp7c-344j",
"modified": "2025-11-04T00:31:12Z",
"published": "2024-08-17T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42274"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/36c255db5a25edd42d1aca48e38b8e95ee5fd9ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3dab73ab925a51ab05543b491bf17463a48ca323"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c07220cf634002f93a87ca2252a32766850f2d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b239a37d68e8bc59f9516444da222841e3b13ba9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5043e69aeb2786f32e84132817a007a6430aa7d"
},
{
"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: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.