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-7RCP-W8X8-MH8F
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-10-03 15:31In the Linux kernel, the following vulnerability has been resolved:
io_uring/rsrc: don't lock while !TASK_RUNNING
There is a report of io_rsrc_ref_quiesce() locking a mutex while not TASK_RUNNING, which is due to forgetting restoring the state back after io_run_task_work_sig() and attempts to break out of the waiting loop.
do not call blocking ops when !TASK_RUNNING; state=1 set at [] prepare_to_wait+0xa4/0x380 kernel/sched/wait.c:237 WARNING: CPU: 2 PID: 397056 at kernel/sched/core.c:10099 __might_sleep+0x114/0x160 kernel/sched/core.c:10099 RIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099 Call Trace: __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0xb4/0x940 kernel/locking/mutex.c:752 io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253 io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799 __io_uring_register io_uring/register.c:424 [inline] __do_sys_io_uring_register+0x5b9/0x2400 io_uring/register.c:613 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77
{
"affected": [],
"aliases": [
"CVE-2024-40922"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/rsrc: don\u0027t lock while !TASK_RUNNING\n\nThere is a report of io_rsrc_ref_quiesce() locking a mutex while not\nTASK_RUNNING, which is due to forgetting restoring the state back after\nio_run_task_work_sig() and attempts to break out of the waiting loop.\n\ndo not call blocking ops when !TASK_RUNNING; state=1 set at\n[\u003cffffffff815d2494\u003e] prepare_to_wait+0xa4/0x380\nkernel/sched/wait.c:237\nWARNING: CPU: 2 PID: 397056 at kernel/sched/core.c:10099\n__might_sleep+0x114/0x160 kernel/sched/core.c:10099\nRIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099\nCall Trace:\n \u003cTASK\u003e\n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0xb4/0x940 kernel/locking/mutex.c:752\n io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253\n io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799\n __io_uring_register io_uring/register.c:424 [inline]\n __do_sys_io_uring_register+0x5b9/0x2400 io_uring/register.c:613\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x6f/0x77",
"id": "GHSA-7rcp-w8x8-mh8f",
"modified": "2025-10-03T15:31:13Z",
"published": "2024-07-12T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40922"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c9df3df0c888d9ec8d11a68474a4aa04d371cff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4429c6c77e176a4c5aa7a3bbd1632f9fc0582518"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/54559642b96116b45e4b5ca7fd9f7835b8561272"
}
],
"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-7RJ5-G3MR-XMP6
Vulnerability from github – Published: 2025-09-05 18:31 – Updated: 2025-11-25 21:32In the Linux kernel, the following vulnerability has been resolved:
media: mt9m114: Fix deadlock in get_frame_interval/set_frame_interval
Getting / Setting the frame interval using the V4L2 subdev pad ops get_frame_interval/set_frame_interval causes a deadlock, as the subdev state is locked in the [1] but also in the driver itself.
In [2] it's described that the caller is responsible to acquire and release the lock in this case. Therefore, acquiring the lock in the driver is wrong.
Remove the lock acquisitions/releases from mt9m114_ifp_get_frame_interval() and mt9m114_ifp_set_frame_interval().
[1] drivers/media/v4l2-core/v4l2-subdev.c - line 1129 [2] Documentation/driver-api/media/v4l2-subdev.rst
{
"affected": [],
"aliases": [
"CVE-2025-39712"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-05T18:15:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mt9m114: Fix deadlock in get_frame_interval/set_frame_interval\n\nGetting / Setting the frame interval using the V4L2 subdev pad ops\nget_frame_interval/set_frame_interval causes a deadlock, as the\nsubdev state is locked in the [1] but also in the driver itself.\n\nIn [2] it\u0027s described that the caller is responsible to acquire and\nrelease the lock in this case. Therefore, acquiring the lock in the\ndriver is wrong.\n\nRemove the lock acquisitions/releases from mt9m114_ifp_get_frame_interval()\nand mt9m114_ifp_set_frame_interval().\n\n[1] drivers/media/v4l2-core/v4l2-subdev.c - line 1129\n[2] Documentation/driver-api/media/v4l2-subdev.rst",
"id": "GHSA-7rj5-g3mr-xmp6",
"modified": "2025-11-25T21:32:04Z",
"published": "2025-09-05T18:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39712"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d23b548d71e5d76955fdf1d73addd8f6494f602"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/298d1471cf83d5a2a05970e41822a2403f451086"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41b97490a1656bdc7038d6345a84b08d45deafc6"
}
],
"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-7RMQ-9HG9-V4Q5
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-15 15:30In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: Workaround SQM/PSE stalls by disabling sticky
NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated.
work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21)
These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations.
{
"affected": [],
"aliases": [
"CVE-2026-43296"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:36Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-af: Workaround SQM/PSE stalls by disabling sticky\n\nNIX SQ manager sticky mode is known to cause stalls when multiple SQs\nshare an SMQ and transmit concurrently. Additionally, PSE may deadlock\non transitions between sticky and non-sticky transmissions. There is\nalso a credit drop issue observed when certain condition clocks are\ngated.\n\nwork around these hardware errata by:\n- Disabling SQM sticky operation:\n - Clear TM6 (bit 15)\n - Clear TM11 (bit 14)\n- Disabling sticky \u2192 non-sticky transition path that can deadlock PSE:\n - Clear TM5 (bit 23)\n- Preventing credit drops by keeping the control-flow clock enabled:\n - Set TM9 (bit 21)\n\nThese changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this\nconfiguration the SQM/PSE maintain forward progress under load without\ncredit loss, at the cost of disabling sticky optimizations.",
"id": "GHSA-7rmq-9hg9-v4q5",
"modified": "2026-05-15T15:30:33Z",
"published": "2026-05-08T15:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43296"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/36cc5a5e0178d5fb79e04173b8aa623b0108819a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/70e9a5760abfb6338d63994d4de6b0778ec795d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8052d0587fb14b85539c3a14a226586c0c3d6b4c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a3fd301329474f449e75f86d8a4f6b9c603fd6c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7eba260a34e854e2487b8363c11976f082df00d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cec2ceb35ce7bc874c43812bb39200d6cf691b87"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0b3c8a80336029d9356f429151eb27922d80a3c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d9b549b6951ba178ec14339a031cae65f4e43fe1"
}
],
"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-7RPW-5262-46CF
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
accel/ivpu: Fix deadlock in context_xa
ivpu_device->context_xa is locked both in kernel thread and IRQ context. It requires XA_FLAGS_LOCK_IRQ flag to be passed during initialization otherwise the lock could be acquired from a thread and interrupted by an IRQ that locks it for the second time causing the deadlock.
This deadlock was reported by lockdep and observed in internal tests.
{
"affected": [],
"aliases": [
"CVE-2024-35953"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix deadlock in context_xa\n\nivpu_device-\u003econtext_xa is locked both in kernel thread and IRQ context.\nIt requires XA_FLAGS_LOCK_IRQ flag to be passed during initialization\notherwise the lock could be acquired from a thread and interrupted by\nan IRQ that locks it for the second time causing the deadlock.\n\nThis deadlock was reported by lockdep and observed in internal tests.",
"id": "GHSA-7rpw-5262-46cf",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-20T12:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35953"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d43e11d9c7fcb16f18bd46ab2556c2772ffc5775"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e6011411147209bc0cc14628cbc155356837e52a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd7726e75968b27fe98534ccbf47ccd6fef686f3"
}
],
"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-7V6R-2W32-RRQ7
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 15:33In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix deadlock with check operation and nowait requests
When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case.
This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0.
Output of r10conf state of the array when we hit this condition:
crash> struct r10conf barrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0,
Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier():
md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30
kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30
{
"affected": [],
"aliases": [
"CVE-2026-46050"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix deadlock with check operation and nowait requests\n\nWhen an array check is running it will raise the barrier at which point\nnormal requests will become blocked and increment the nr_pending value to\nsignal there is work pending inside of wait_barrier(). NOWAIT requests\ndo not block and so will return immediately with an error, and additionally\ndo not increment nr_pending in wait_barrier(). Upstream change commit\n43806c3d5b9b (\"raid10: cleanup memleak at raid10_make_request\") added a\ncall to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit\nthis condition. raid_end_bio_io() eventually calls allow_barrier() and\nit will unconditionally do an atomic_dec_and_test(\u0026conf-\u003enr_pending) even\nthough the corresponding increment on nr_pending didn\u0027t happen in the\nNOWAIT case.\n\nThis can be easily seen by starting a check operation while an application\nis doing nowait IO on the same array. This results in a deadlocked state\ndue to nr_pending value underflowing and so the md resync thread gets stuck\nwaiting for nr_pending to == 0.\n\nOutput of r10conf state of the array when we hit this condition:\n\ncrash\u003e struct r10conf\n\tbarrier = 1,\n nr_pending = {\n counter = -41\n },\n nr_waiting = 15,\n nr_queued = 0,\n\nExample of md_sync thread stuck waiting on raise_barrier() and other\nrequests stuck in wait_barrier():\n\nmd1_resync\n[\u003c0\u003e] raise_barrier+0xce/0x1c0\n[\u003c0\u003e] raid10_sync_request+0x1ca/0x1ed0\n[\u003c0\u003e] md_do_sync+0x779/0x1110\n[\u003c0\u003e] md_thread+0x90/0x160\n[\u003c0\u003e] kthread+0xbe/0xf0\n[\u003c0\u003e] ret_from_fork+0x34/0x50\n[\u003c0\u003e] ret_from_fork_asm+0x1a/0x30\n\nkworker/u1040:2+flush-253:4\n[\u003c0\u003e] wait_barrier+0x1de/0x220\n[\u003c0\u003e] regular_request_wait+0x30/0x180\n[\u003c0\u003e] raid10_make_request+0x261/0x1000\n[\u003c0\u003e] md_handle_request+0x13b/0x230\n[\u003c0\u003e] __submit_bio+0x107/0x1f0\n[\u003c0\u003e] submit_bio_noacct_nocheck+0x16f/0x390\n[\u003c0\u003e] ext4_io_submit+0x24/0x40\n[\u003c0\u003e] ext4_do_writepages+0x254/0xc80\n[\u003c0\u003e] ext4_writepages+0x84/0x120\n[\u003c0\u003e] do_writepages+0x7a/0x260\n[\u003c0\u003e] __writeback_single_inode+0x3d/0x300\n[\u003c0\u003e] writeback_sb_inodes+0x1dd/0x470\n[\u003c0\u003e] __writeback_inodes_wb+0x4c/0xe0\n[\u003c0\u003e] wb_writeback+0x18b/0x2d0\n[\u003c0\u003e] wb_workfn+0x2a1/0x400\n[\u003c0\u003e] process_one_work+0x149/0x330\n[\u003c0\u003e] worker_thread+0x2d2/0x410\n[\u003c0\u003e] kthread+0xbe/0xf0\n[\u003c0\u003e] ret_from_fork+0x34/0x50\n[\u003c0\u003e] ret_from_fork_asm+0x1a/0x30",
"id": "GHSA-7v6r-2w32-rrq7",
"modified": "2026-06-16T15:33:41Z",
"published": "2026-05-27T15:33:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46050"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1cdff2937c618f81058422bbdc4974a3e7ec9379"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2249983d971e6839b36284e6610390b2c217dfa1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/42fe37c90184cd1568838b84b488934c3671c963"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d96f3120a7fb7210d21b520c5b6f495da6ba436"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/965d6162dd88cc7cc193cf7f5bfc132d8bbf0523"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae356d5eb1331d678985799f893e436314834a87"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cac2106bb9a2180b288079b49ed626414fb5bc45"
}
],
"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-7VJH-PRMQ-CFM3
Vulnerability from github – Published: 2024-03-11 18:31 – Updated: 2024-12-12 18:30In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: host: Drop chan lock before queuing buffers
Ensure read and write locks for the channel are not taken in succession by dropping the read lock from parse_xfer_event() such that a callback given to client can potentially queue buffers and acquire the write lock in that process. Any queueing of buffers should be done without channel read lock acquired as it can result in multiple locks and a soft lockup.
[mani: added fixes tag and cc'ed stable]
{
"affected": [],
"aliases": [
"CVE-2023-52493"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-11T18:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: host: Drop chan lock before queuing buffers\n\nEnsure read and write locks for the channel are not taken in succession by\ndropping the read lock from parse_xfer_event() such that a callback given\nto client can potentially queue buffers and acquire the write lock in that\nprocess. Any queueing of buffers should be done without channel read lock\nacquired as it can result in multiple locks and a soft lockup.\n\n[mani: added fixes tag and cc\u0027ed stable]",
"id": "GHSA-7vjh-prmq-cfm3",
"modified": "2024-12-12T18:30:50Z",
"published": "2024-03-11T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52493"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/01bd694ac2f682fb8017e16148b928482bc8fa4b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c5ec66b4b3f6816f3a6161538672e389e537690"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e4c84316e2b70709f0d00c33ba3358d9fc8eece"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b8eff20d87092e14cac976d057cb0aea2f1d0830"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eaefb9464031215d63c0a8a7e2bfaa00736aa17e"
},
{
"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"
}
]
}
GHSA-7W4W-2HXM-8CC6
Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2022-12-01 00:30A race condition in perf_event_open() allows local attackers to leak sensitive data from setuid programs. As no relevant locks (in particular the cred_guard_mutex) are held during the ptrace_may_access() call, it is possible for the specified target task to perform an execve() syscall with setuid execution before perf_event_alloc() actually attaches to it, allowing an attacker to bypass the ptrace_may_access() check and the perf_event_exit_task(current) call that is performed in install_exec_creds() during privileged execve() calls. This issue affects kernel versions before 4.8.
{
"affected": [],
"aliases": [
"CVE-2019-3901"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-22T16:29:00Z",
"severity": "MODERATE"
},
"details": "A race condition in perf_event_open() allows local attackers to leak sensitive data from setuid programs. As no relevant locks (in particular the cred_guard_mutex) are held during the ptrace_may_access() call, it is possible for the specified target task to perform an execve() syscall with setuid execution before perf_event_alloc() actually attaches to it, allowing an attacker to bypass the ptrace_may_access() check and the perf_event_exit_task(current) call that is performed in install_exec_creds() during privileged execve() calls. This issue affects kernel versions before 4.8.",
"id": "GHSA-7w4w-2hxm-8cc6",
"modified": "2022-12-01T00:30:42Z",
"published": "2022-05-24T16:44:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3901"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:1016"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:1070"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:2522"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:2851"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2019-3901"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1701245"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3901"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/05/msg00041.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/05/msg00042.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190517-0005"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/89937"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7XJ4-QJ2W-MPF9
Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-12-16 21:30In the Linux kernel, the following vulnerability has been resolved:
iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo
Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.
{
"affected": [],
"aliases": [
"CVE-2025-37970"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T17:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo\n\nPrevent st_lsm6dsx_read_fifo from falling in an infinite loop in case\npattern_len is equal to zero and the device FIFO is not empty.",
"id": "GHSA-7xj4-qj2w-mpf9",
"modified": "2025-12-16T21:30:49Z",
"published": "2025-05-20T18:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37970"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/159ca7f18129834b6f4c7eae67de48e96c752fc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3bb6c02d6fe8347ce1785016d135ff539c20043c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c4a5000618a8c44200d455c92e2f2a4db264717"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84e39f628a3a3333add99076e4d6c8b42b12d3a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1cad8a3bca41dead9980615d35efc7bff1fd534"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/da33c4167b9cc1266a97215114cb74679f881d0c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f06a1a1954527cc4ed086d926c81ff236b2adde9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f3cf233c946531a92fe651ff2bd15ebbe60630a7"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.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-8235-3268-FJF9
Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-05-24 19:13The Bluetooth Classic implementation on Actions ATS2815 and ATS2819 chipsets does not properly handle the reception of multiple LMP_host_connection_req packets, allowing attackers in radio range to trigger a denial of service (deadlock) of the device via crafted LMP packets. Manual user intervention is required to restart the device and restore Bluetooth communication.
{
"affected": [],
"aliases": [
"CVE-2021-31785"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-07T07:15:00Z",
"severity": "MODERATE"
},
"details": "The Bluetooth Classic implementation on Actions ATS2815 and ATS2819 chipsets does not properly handle the reception of multiple LMP_host_connection_req packets, allowing attackers in radio range to trigger a denial of service (deadlock) of the device via crafted LMP packets. Manual user intervention is required to restart the device and restore Bluetooth communication.",
"id": "GHSA-8235-3268-fjf9",
"modified": "2022-05-24T19:13:16Z",
"published": "2022-05-24T19:13:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31785"
},
{
"type": "WEB",
"url": "https://dl.packetstormsecurity.net/papers/general/braktooth.pdf"
},
{
"type": "WEB",
"url": "https://launchstudio.bluetooth.com/ListingDetails/76427"
},
{
"type": "WEB",
"url": "https://www.actions-semi.com/index.php?id=3581\u0026siteId=4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-82WR-7889-862X
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-14 21:32In the Linux kernel, the following vulnerability has been resolved:
ptdma: pt_core_execute_cmd() should use spinlock
The interrupt handler (pt_core_irq_handler()) of the ptdma driver can be called from interrupt context. The code flow in this function can lead down to pt_core_execute_cmd() which will attempt to grab a mutex, which is not appropriate in interrupt context and ultimately leads to a kernel panic. The fix here changes this mutex to a spinlock, which has been verified to resolve the issue.
{
"affected": [],
"aliases": [
"CVE-2023-53013"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:50Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nptdma: pt_core_execute_cmd() should use spinlock\n\nThe interrupt handler (pt_core_irq_handler()) of the ptdma\ndriver can be called from interrupt context. The code flow\nin this function can lead down to pt_core_execute_cmd() which\nwill attempt to grab a mutex, which is not appropriate in\ninterrupt context and ultimately leads to a kernel panic.\nThe fix here changes this mutex to a spinlock, which has\nbeen verified to resolve the issue.",
"id": "GHSA-82wr-7889-862x",
"modified": "2025-04-14T21:32:23Z",
"published": "2025-03-27T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53013"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13ba563c2c8055ba8a637c9f70bb833b43cb4207"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95e5fda3b5f9ed8239b145da3fa01e641cf5d53c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ed0d8f731e0bf1bb12a7a37698ac613db20e2794"
}
],
"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.