CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
713 vulnerabilities reference this CWE, most recent first.
GHSA-GHRP-FHCH-VVR7
Vulnerability from github – Published: 2025-03-17 21:30 – Updated: 2025-03-17 21:30In the Linux kernel, the following vulnerability has been resolved:
loop: implement ->free_disk
Ensure that the lo_device which is stored in the gendisk private data is valid until the gendisk is freed. Currently the loop driver uses a lot of effort to make sure a device is not freed when it is still in use, but to to fix a potential deadlock this will be relaxed a bit soon.
{
"affected": [],
"aliases": [
"CVE-2022-49531"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nloop: implement -\u003efree_disk\n\nEnsure that the lo_device which is stored in the gendisk private\ndata is valid until the gendisk is freed. Currently the loop driver\nuses a lot of effort to make sure a device is not freed when it is\nstill in use, but to to fix a potential deadlock this will be relaxed\na bit soon.",
"id": "GHSA-ghrp-fhch-vvr7",
"modified": "2025-03-17T21:30:33Z",
"published": "2025-03-17T21:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49531"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aadd1443aae7fe8956e3b11157827067f034406a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2c7f56f8b5256d57f9e3fc7794c31361d43bdd9"
}
],
"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-GJ5H-7FQ5-56P5
Vulnerability from github – Published: 2025-04-16 15:34 – Updated: 2025-11-03 18:31In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix potential deadloop in prepare_compress_overwrite()
Jan Prusakowski reported a kernel hang issue as below:
When running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I encountered a problem in generic/475 test where fsstress process gets blocked in __f2fs_write_data_pages() and the test hangs. The options I used are:
MKFS_OPTIONS -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc
INFO: task kworker/u8:0:11 blocked for more than 122 seconds. Not tainted 6.14.0-rc3-xfstests-lockdep #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:0 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208160 flags:0x00004000 Workqueue: writeback wb_workfn (flush-253:0) Call Trace: __schedule+0x309/0x8e0 schedule+0x3a/0x100 schedule_preempt_disabled+0x15/0x30 __mutex_lock+0x59a/0xdb0 __f2fs_write_data_pages+0x3ac/0x400 do_writepages+0xe8/0x290 __writeback_single_inode+0x5c/0x360 writeback_sb_inodes+0x22f/0x570 wb_writeback+0xb0/0x410 wb_do_writeback+0x47/0x2f0 wb_workfn+0x5a/0x1c0 process_one_work+0x223/0x5b0 worker_thread+0x1d5/0x3c0 kthread+0xfd/0x230 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30
The root cause is: once generic/475 starts toload error table to dm device, f2fs_prepare_compress_overwrite() will loop reading compressed cluster pages due to IO error, meanwhile it has held .writepages lock, it can block all other writeback tasks.
Let's fix this issue w/ below changes: - add f2fs_handle_page_eio() in prepare_compress_overwrite() to detect IO error. - detect cp_error earler in f2fs_read_multi_pages().
{
"affected": [],
"aliases": [
"CVE-2025-22127"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T15:16:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix potential deadloop in prepare_compress_overwrite()\n\nJan Prusakowski reported a kernel hang issue as below:\n\nWhen running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I\nencountered a problem in generic/475 test where fsstress process\ngets blocked in __f2fs_write_data_pages() and the test hangs.\nThe options I used are:\n\nMKFS_OPTIONS -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc\nMOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc\n\nINFO: task kworker/u8:0:11 blocked for more than 122 seconds.\n Not tainted 6.14.0-rc3-xfstests-lockdep #1\n\"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:kworker/u8:0 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208160 flags:0x00004000\nWorkqueue: writeback wb_workfn (flush-253:0)\nCall Trace:\n \u003cTASK\u003e\n __schedule+0x309/0x8e0\n schedule+0x3a/0x100\n schedule_preempt_disabled+0x15/0x30\n __mutex_lock+0x59a/0xdb0\n __f2fs_write_data_pages+0x3ac/0x400\n do_writepages+0xe8/0x290\n __writeback_single_inode+0x5c/0x360\n writeback_sb_inodes+0x22f/0x570\n wb_writeback+0xb0/0x410\n wb_do_writeback+0x47/0x2f0\n wb_workfn+0x5a/0x1c0\n process_one_work+0x223/0x5b0\n worker_thread+0x1d5/0x3c0\n kthread+0xfd/0x230\n ret_from_fork+0x31/0x50\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\nThe root cause is: once generic/475 starts toload error table to dm\ndevice, f2fs_prepare_compress_overwrite() will loop reading compressed\ncluster pages due to IO error, meanwhile it has held .writepages lock,\nit can block all other writeback tasks.\n\nLet\u0027s fix this issue w/ below changes:\n- add f2fs_handle_page_eio() in prepare_compress_overwrite() to\ndetect IO error.\n- detect cp_error earler in f2fs_read_multi_pages().",
"id": "GHSA-gj5h-7fq5-56p5",
"modified": "2025-11-03T18:31:15Z",
"published": "2025-04-16T15:34:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22127"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3147ee567dd9004a49826ddeaf0a4b12865d4409"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7215cf8ef54bdc9082dffac4662416d54961e258"
}
],
"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-GJ8M-4CCW-V82H
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-06-03 18:55In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
When disabling aRFS under the priv->state_lock, any scheduled
aRFS works are canceled using the cancel_work_sync function,
which waits for the work to end if it has already started.
However, while waiting for the work handler, the handler will
try to acquire the state_lock which is already acquired.
The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules.
Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled.
Kernel log:
====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I
ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20
-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work));
*** DEADLOCK ***
3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-27014"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:20Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Prevent deadlock while disabling aRFS\n\nWhen disabling aRFS under the `priv-\u003estate_lock`, any scheduled\naRFS works are canceled using the `cancel_work_sync` function,\nwhich waits for the work to end if it has already started.\nHowever, while waiting for the work handler, the handler will\ntry to acquire the `state_lock` which is already acquired.\n\nThe worker acquires the lock to delete the rules if the state\nis down, which is not the worker\u0027s responsibility since\ndisabling aRFS deletes the rules.\n\nAdd an aRFS state variable, which indicates whether the aRFS is\nenabled and prevent adding rules when the aRFS is disabled.\n\nKernel log:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I\n------------------------------------------------------\nethtool/386089 is trying to acquire lock:\nffff88810f21ce68 ((work_completion)(\u0026rule-\u003earfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0\n\nbut task is already holding lock:\nffff8884a1808cc0 (\u0026priv-\u003estate_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #1 (\u0026priv-\u003estate_lock){+.+.}-{3:3}:\n __mutex_lock+0x80/0xc90\n arfs_handle_work+0x4b/0x3b0 [mlx5_core]\n process_one_work+0x1dc/0x4a0\n worker_thread+0x1bf/0x3c0\n kthread+0xd7/0x100\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n\n-\u003e #0 ((work_completion)(\u0026rule-\u003earfs_work)){+.+.}-{0:0}:\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n __flush_work+0x7a/0x4e0\n __cancel_work_timer+0x131/0x1c0\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n netlink_rcv_skb+0x54/0x100\n genl_rcv+0x24/0x40\n netlink_unicast+0x1a1/0x270\n netlink_sendmsg+0x214/0x460\n __sock_sendmsg+0x38/0x60\n __sys_sendto+0x113/0x170\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x40/0xe0\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026priv-\u003estate_lock);\n lock((work_completion)(\u0026rule-\u003earfs_work));\n lock(\u0026priv-\u003estate_lock);\n lock((work_completion)(\u0026rule-\u003earfs_work));\n\n *** DEADLOCK ***\n\n3 locks held by ethtool/386089:\n #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40\n #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240\n #2: ffff8884a1808cc0 (\u0026priv-\u003estate_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\n\nstack backtrace:\nCPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x60/0xa0\n check_noncircular+0x144/0x160\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n ? __flush_work+0x74/0x4e0\n ? save_trace+0x3e/0x360\n ? __flush_work+0x74/0x4e0\n __flush_work+0x7a/0x4e0\n ? __flush_work+0x74/0x4e0\n ? __lock_acquire+0xa78/0x2c80\n ? lock_acquire+0xd0/0x2b0\n ? mark_held_locks+0x49/0x70\n __cancel_work_timer+0x131/0x1c0\n ? mark_held_locks+0x49/0x70\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n ? ethn\n---truncated---",
"id": "GHSA-gj8m-4ccw-v82h",
"modified": "2024-06-03T18:55:52Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27014"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
}
],
"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-GJRX-W6PW-88PH
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-05 15:31In the Linux kernel, the following vulnerability has been resolved:
md: fix soft lockup in status_resync
status_resync() will calculate 'curr_resync - recovery_active' to show user a progress bar like following:
[============>........] resync = 61.4%
'curr_resync' and 'recovery_active' is updated in md_do_sync(), and status_resync() can read them concurrently, hence it's possible that 'curr_resync - recovery_active' can overflow to a huge number. In this case status_resync() will be stuck in the loop to print a large amount of '=', which will end up soft lockup.
Fix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case, this way resync in progress will be reported to user.
{
"affected": [],
"aliases": [
"CVE-2023-53620"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix soft lockup in status_resync\n\nstatus_resync() will calculate \u0027curr_resync - recovery_active\u0027 to show\nuser a progress bar like following:\n\n[============\u003e........] resync = 61.4%\n\n\u0027curr_resync\u0027 and \u0027recovery_active\u0027 is updated in md_do_sync(), and\nstatus_resync() can read them concurrently, hence it\u0027s possible that\n\u0027curr_resync - recovery_active\u0027 can overflow to a huge number. In this\ncase status_resync() will be stuck in the loop to print a large amount\nof \u0027=\u0027, which will end up soft lockup.\n\nFix the problem by setting \u0027resync\u0027 to MD_RESYNC_ACTIVE in this case,\nthis way resync in progress will be reported to user.",
"id": "GHSA-gjrx-w6pw-88ph",
"modified": "2026-02-05T15:31:08Z",
"published": "2025-10-07T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53620"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/23309704e90859af2662bedc44101e6d1d2ece7e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6efddf1e32e2a264694766ca485a4f5e04ee82a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4acb6c3ede88d6b7d33742a09e63cfce5e7fb69"
}
],
"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-GM6W-HJ88-5F6C
Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-05-24 19:18In ccu, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS05594996; Issue ID: ALPS05594996.
{
"affected": [],
"aliases": [
"CVE-2021-0625"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-25T14:15:00Z",
"severity": "HIGH"
},
"details": "In ccu, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS05594996; Issue ID: ALPS05594996.",
"id": "GHSA-gm6w-hj88-5f6c",
"modified": "2022-05-24T19:18:46Z",
"published": "2022-05-24T19:18:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0625"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/October-2021"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GP83-H9GH-VRV6
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-11-01 15:31In the Linux kernel, the following vulnerability has been resolved:
net: systemport: Add global locking for descriptor lifecycle
The descriptor list is a shared resource across all of the transmit queues, and the locking mechanism used today only protects concurrency across a given transmit queue between the transmit and reclaiming. This creates an opportunity for the SYSTEMPORT hardware to work on corrupted descriptors if we have multiple producers at once which is the case when using multiple transmit queues.
This was particularly noticeable when using multiple flows/transmit queues and it showed up in interesting ways in that UDP packets would get a correct UDP header checksum being calculated over an incorrect packet length. Similarly TCP packets would get an equally correct checksum computed by the hardware over an incorrect packet length.
The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges when the driver produces a new descriptor anytime it writes to the WRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to re-organize its descriptors and it is possible that concurrent TX queues eventually break this internal allocation scheme to the point where the length/status part of the descriptor gets used for an incorrect data buffer.
The fix is to impose a global serialization for all TX queues in the short section where we are writing to the WRITE_PORT_{HI,LO} registers which solves the corruption even with multiple concurrent TX queues being used.
{
"affected": [],
"aliases": [
"CVE-2021-47587"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T15:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: systemport: Add global locking for descriptor lifecycle\n\nThe descriptor list is a shared resource across all of the transmit queues, and\nthe locking mechanism used today only protects concurrency across a given\ntransmit queue between the transmit and reclaiming. This creates an opportunity\nfor the SYSTEMPORT hardware to work on corrupted descriptors if we have\nmultiple producers at once which is the case when using multiple transmit\nqueues.\n\nThis was particularly noticeable when using multiple flows/transmit queues and\nit showed up in interesting ways in that UDP packets would get a correct UDP\nheader checksum being calculated over an incorrect packet length. Similarly TCP\npackets would get an equally correct checksum computed by the hardware over an\nincorrect packet length.\n\nThe SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges\nwhen the driver produces a new descriptor anytime it writes to the\nWRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to\nre-organize its descriptors and it is possible that concurrent TX queues\neventually break this internal allocation scheme to the point where the\nlength/status part of the descriptor gets used for an incorrect data buffer.\n\nThe fix is to impose a global serialization for all TX queues in the short\nsection where we are writing to the WRITE_PORT_{HI,LO} registers which solves\nthe corruption even with multiple concurrent TX queues being used.",
"id": "GHSA-gp83-h9gh-vrv6",
"modified": "2024-11-01T15:31:45Z",
"published": "2024-06-19T15:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47587"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/595a684fa6f23b21958379a18cfa83862c73c2e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e1011cd183faae8daff275c72444edcdfe0d473"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b8e6e782456f1ce02a7ae914bbd5b1053f0b034"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ed2f5d08d6e59f8c78b2869bfb95d0be32c094c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c675256a7f131f5ba3f331efb715e8f31ea0e392"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de57f62f76450b934de8203711bdc4f7953c3421"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb4687c7442942e115420a30185f8d83faf37696"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f3fde37d3f0d429f0fcce214cb52588a9e21260e"
}
],
"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-GR3W-P7MM-8PCQ
Vulnerability from github – Published: 2024-08-08 09:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
gpio: pca953x: fix pca953x_irq_bus_sync_unlock race
Ensure that `i2c_lock' is held when setting interrupt latch and mask in pca953x_irq_bus_sync_unlock() in order to avoid races.
The other (non-probe) call site pca953x_gpio_set_multiple() ensures the lock is held before calling pca953x_write_regs().
The problem occurred when a request raced against irq_bus_sync_unlock() approximately once per thousand reboots on an i.MX8MP based system.
- Normal case
0-0022: write register AI|3a {03,02,00,00,01} Input latch P0 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|12 {fc,00,00,00,00} Config P3
- Race case
0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register *** 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
{
"affected": [],
"aliases": [
"CVE-2024-42253"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-08T09:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: pca953x: fix pca953x_irq_bus_sync_unlock race\n\nEnsure that `i2c_lock\u0027 is held when setting interrupt latch and mask in\npca953x_irq_bus_sync_unlock() in order to avoid races.\n\nThe other (non-probe) call site pca953x_gpio_set_multiple() ensures the\nlock is held before calling pca953x_write_regs().\n\nThe problem occurred when a request raced against irq_bus_sync_unlock()\napproximately once per thousand reboots on an i.MX8MP based system.\n\n * Normal case\n\n 0-0022: write register AI|3a {03,02,00,00,01} Input latch P0\n 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0\n 0-0022: write register AI|08 {ff,00,00,00,00} Output P3\n 0-0022: write register AI|12 {fc,00,00,00,00} Config P3\n\n * Race case\n\n 0-0022: write register AI|08 {ff,00,00,00,00} Output P3\n 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register ***\n 0-0022: write register AI|12 {fc,00,00,00,00} Config P3\n 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0",
"id": "GHSA-gr3w-p7mm-8pcq",
"modified": "2025-11-04T00:31:11Z",
"published": "2024-08-08T09:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42253"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/58a5c93bd1a6e949267400080f07e57ffe05ec34"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfc6444b57dc7186b6acc964705d7516cbaf3904"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de7cffa53149c7b48bd1bb29b02390c9f05b7f41"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2ecdddca80dd845df42376e4b0197fe97018ba2"
},
{
"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:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GR8X-8Q27-R5GG
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
ALSA: caiaq: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close.
This patch also splits the code to the disconnect and the free phases; the former is called immediately at the USB disconnect callback while the latter is called from the card destructor.
{
"affected": [],
"aliases": [
"CVE-2024-56531"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: caiaq: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.\n\nThis patch also splits the code to the disconnect and the free phases;\nthe former is called immediately at the USB disconnect callback while\nthe latter is called from the card destructor.",
"id": "GHSA-gr8x-8q27-r5gg",
"modified": "2025-11-03T21:31:50Z",
"published": "2024-12-27T15:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56531"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/237f3faf0177bdde728fa3106d730d806436aa4d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3993edf44d3df7b6e8c753eac6ac8783473fcbab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4507a8b9b30344c5ddd8219945f446d47e966a6d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4dd821dcbfcecf7af6a08370b0b217cde2818acf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3f9314752dbb6f6aa1f0f2b4c58243bda800738"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b04dcbb7f7b1908806b7dc22671cdbe78ff2b82c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cadf1d8e9ddcd74584ec961aeac14ac549b261d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd0de8cb708951cebf727aa045e8242ba651bb52"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ebad462eec93b0f701dfe4de98990e7355283801"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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-GRQ2-2V86-6PPX
Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-05-24 19:13The Bluetooth Classic implementation on Zhuhai Jieli AC690X and AC692X devices does not properly handle an out-of-order LMP Setup procedure that is followed by a malformed LMP packet, allowing attackers in radio range to deadlock a device via a crafted LMP packet. The user needs to manually reboot the device to restore communication.
{
"affected": [],
"aliases": [
"CVE-2021-31611"
],
"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 Zhuhai Jieli AC690X and AC692X devices does not properly handle an out-of-order LMP Setup procedure that is followed by a malformed LMP packet, allowing attackers in radio range to deadlock a device via a crafted LMP packet. The user needs to manually reboot the device to restore communication.",
"id": "GHSA-grq2-2v86-6ppx",
"modified": "2022-05-24T19:13:16Z",
"published": "2022-05-24T19:13:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31611"
},
{
"type": "WEB",
"url": "https://dl.packetstormsecurity.net/papers/general/braktooth.pdf"
},
{
"type": "WEB",
"url": "https://launchstudio.bluetooth.com/ListingDetails/19746"
},
{
"type": "WEB",
"url": "https://launchstudio.bluetooth.com/ListingDetails/58628"
},
{
"type": "WEB",
"url": "http://www.zh-jieli.com/product/68-cn.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GRRP-5MC5-CCMG
Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30In the Linux kernel, the following vulnerability has been resolved:
NFSv4: Don't hold the layoutget locks across multiple RPC calls
When doing layoutget as part of the open() compound, we have to be careful to release the layout locks before we can call any further RPC calls, such as setattr(). The reason is that those calls could trigger a recall, which could deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-49316"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4: Don\u0027t hold the layoutget locks across multiple RPC calls\n\nWhen doing layoutget as part of the open() compound, we have to be\ncareful to release the layout locks before we can call any further RPC\ncalls, such as setattr(). The reason is that those calls could trigger\na recall, which could deadlock.",
"id": "GHSA-grrp-5mc5-ccmg",
"modified": "2025-03-14T00:30:51Z",
"published": "2025-03-14T00:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49316"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08d7a26d115cc7892668baa9750f64bd8baca29b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ee5b9644f06b4d3cdcd9544f43f63312e425a4c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6949493884fe88500de4af182588e071cf1544ee"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b3fc1496e7227cd6a39a80bbfb7588ef7c7a010"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a2b3be930e79cc5d9d829f158e31172b2043f0cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4c2a041ed3ba114502d5ed6ace5b1a48d637a8e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea759ae0a9ae5acee677d722129710ac89cc59c1"
}
],
"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.