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-625Q-77GV-32CR
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: us122l: 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.
The loop of us122l->mmap_count check is dropped as well. The check is useless for the asynchronous operation with *_when_closed().
{
"affected": [],
"aliases": [
"CVE-2024-56532"
],
"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: us122l: 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\nThe loop of us122l-\u003emmap_count check is dropped as well. The check is\nuseless for the asynchronous operation with *_when_closed().",
"id": "GHSA-625q-77gv-32cr",
"modified": "2025-11-03T21:31:50Z",
"published": "2024-12-27T15:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56532"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/020cbc4d7414f0962004213e2b7bc5cc607e9ec7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2938dd2648522336133c151dd67bb9bf01cbd390"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75f418b249d84021865eaa59515d3ed9b75ce4d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a48bd2184b142c92a4e17eac074c61fcf975bc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b27924dc8d7f8a8c35e521287d4ccb9a006e597"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d5c530e4d70f64b1114f2cc29ac690ba7ac4a38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7df09bb348016943f56b09dcaafe221e3f73947"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc778ad3e495333eebda36fe91d5b2c93109cc16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf0aa35a7cb8602cccf2387712114e836f65c154"
},
{
"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-62F3-XHHG-6P74
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-11-18 21:32In the Linux kernel, the following vulnerability has been resolved:
s390/mm: Fix in_atomic() handling in do_secure_storage_access()
Kernel user spaces accesses to not exported pages in atomic context incorrectly try to resolve the page fault. With debug options enabled call traces like this can be seen:
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. Preemption disabled at: [<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0 CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39 Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT Tainted: [W]=WARN Hardware name: IBM 3931 A01 703 (LPAR) Call Trace: [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8 [<00000383e99bf152>] __might_resched+0x292/0x2d0 [<00000383eaa7c374>] down_read+0x34/0x2d0 [<00000383e99432f8>] do_secure_storage_access+0x108/0x360 [<00000383eaa724b0>] __do_pgm_check+0x130/0x220 [<00000383eaa842e4>] pgm_check_handler+0x114/0x160 [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0 ([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0) [<00000383e9c45eae>] generic_perform_write+0x16e/0x310 [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160 [<00000383e9da0de4>] vfs_write+0x1c4/0x460 [<00000383e9da123c>] ksys_write+0x7c/0x100 [<00000383eaa7284e>] __do_syscall+0x15e/0x280 [<00000383eaa8417e>] system_call+0x6e/0x90 INFO: lockdep is turned off.
It is not allowed to take the mmap_lock while in atomic context. Therefore handle such a secure storage access fault as if the accessed page is not mapped: the uaccess function will return -EFAULT, and the caller has to deal with this. Usually this means that the access is retried in process context, which allows to resolve the page fault (or in this case export the page).
{
"affected": [],
"aliases": [
"CVE-2025-38359"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T13:15:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390/mm: Fix in_atomic() handling in do_secure_storage_access()\n\nKernel user spaces accesses to not exported pages in atomic context\nincorrectly try to resolve the page fault.\nWith debug options enabled call traces like this can be seen:\n\nBUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39\npreempt_count: 1, expected: 0\nRCU nest depth: 0, expected: 0\nINFO: lockdep is turned off.\nPreemption disabled at:\n[\u003c00000383ea47cfa2\u003e] copy_page_from_iter_atomic+0xa2/0x8a0\nCPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39\nTainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT\nTainted: [W]=WARN\nHardware name: IBM 3931 A01 703 (LPAR)\nCall Trace:\n [\u003c00000383e990d282\u003e] dump_stack_lvl+0xa2/0xe8\n [\u003c00000383e99bf152\u003e] __might_resched+0x292/0x2d0\n [\u003c00000383eaa7c374\u003e] down_read+0x34/0x2d0\n [\u003c00000383e99432f8\u003e] do_secure_storage_access+0x108/0x360\n [\u003c00000383eaa724b0\u003e] __do_pgm_check+0x130/0x220\n [\u003c00000383eaa842e4\u003e] pgm_check_handler+0x114/0x160\n [\u003c00000383ea47d028\u003e] copy_page_from_iter_atomic+0x128/0x8a0\n([\u003c00000383ea47d016\u003e] copy_page_from_iter_atomic+0x116/0x8a0)\n [\u003c00000383e9c45eae\u003e] generic_perform_write+0x16e/0x310\n [\u003c00000383e9eb87f4\u003e] ext4_buffered_write_iter+0x84/0x160\n [\u003c00000383e9da0de4\u003e] vfs_write+0x1c4/0x460\n [\u003c00000383e9da123c\u003e] ksys_write+0x7c/0x100\n [\u003c00000383eaa7284e\u003e] __do_syscall+0x15e/0x280\n [\u003c00000383eaa8417e\u003e] system_call+0x6e/0x90\nINFO: lockdep is turned off.\n\nIt is not allowed to take the mmap_lock while in atomic context. Therefore\nhandle such a secure storage access fault as if the accessed page is not\nmapped: the uaccess function will return -EFAULT, and the caller has to\ndeal with this. Usually this means that the access is retried in process\ncontext, which allows to resolve the page fault (or in this case export the\npage).",
"id": "GHSA-62f3-xhhg-6p74",
"modified": "2025-11-18T21:32:29Z",
"published": "2025-07-25T15:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38359"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/11709abccf93b08adde95ef313c300b0d4bc28f1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2e317dfd2d1fe416c77315d17c5d57dbe374915"
}
],
"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-62JP-4QC2-X9XX
Vulnerability from github – Published: 2022-05-01 02:21 – Updated: 2024-02-15 21:31The handle_stop_signal function in signal.c in Linux kernel 2.6.11 up to other versions before 2.6.13 and 2.6.12.6 allows local users to cause a denial of service (deadlock) by sending a SIGKILL to a real-time threaded process while it is performing a core dump.
{
"affected": [],
"aliases": [
"CVE-2005-3847"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2005-11-27T00:03:00Z",
"severity": "MODERATE"
},
"details": "The handle_stop_signal function in signal.c in Linux kernel 2.6.11 up to other versions before 2.6.13 and 2.6.12.6 allows local users to cause a denial of service (deadlock) by sending a SIGKILL to a real-time threaded process while it is performing a core dump.",
"id": "GHSA-62jp-4qc2-x9xx",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-05-01T02:21:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2005-3847"
},
{
"type": "WEB",
"url": "http://lists.suse.de/archive/suse-security-announce/2006-Feb/0010.html"
},
{
"type": "WEB",
"url": "http://marc.info/?l=linux-kernel\u0026m=112430346613450\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=linux-kernel\u0026m=112508422716574\u0026w=2"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/19038"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/19374"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2006/dsa-1017"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/chrisw/stable-queue.git%3Ba=blob%3Bh=f6cc7e101c49f356e4c4df5cca1ff352a0f01dd5%3Bhb=9c5fcb99af7c157be45e9d53aeb857ded5211fcd%3Bf=2.6.12.6/nptl-signal-delivery-deadlock-fix.patch"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/chrisw/stable-queue.git;a=blob;h=f6cc7e101c49f356e4c4df5cca1ff352a0f01dd5;hb=9c5fcb99af7c157be45e9d53aeb857ded5211fcd;f=2.6.12.6/nptl-signal-delivery-deadlock-fix.patch"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commitdiff%3Bh=dd12f48d4e8774415b528d3991ae47c28f26e1ac%3Bhp=ade6648b3b11a5d81f6f28135193ab6d85d621db"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dd12f48d4e8774415b528d3991ae47c28f26e1ac;hp=ade6648b3b11a5d81f6f28135193ab6d85d621db"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/16856"
}
],
"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-637R-5W8J-MJG6
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2026-04-18 09:30In the Linux kernel, the following vulnerability has been resolved:
drm/scheduler: signal scheduled fence when kill job
When an entity from application B is killed, drm_sched_entity_kill() removes all jobs belonging to that entity through drm_sched_entity_kill_jobs_work(). If application A's job depends on a scheduled fence from application B's job, and that fence is not properly signaled during the killing process, application A's dependency cannot be cleared.
This leads to application A hanging indefinitely while waiting for a dependency that will never be resolved. Fix this issue by ensuring that scheduled fences are properly signaled when an entity is killed, allowing dependent applications to continue execution.
{
"affected": [],
"aliases": [
"CVE-2025-38436"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T15:15:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/scheduler: signal scheduled fence when kill job\n\nWhen an entity from application B is killed, drm_sched_entity_kill()\nremoves all jobs belonging to that entity through\ndrm_sched_entity_kill_jobs_work(). If application A\u0027s job depends on a\nscheduled fence from application B\u0027s job, and that fence is not properly\nsignaled during the killing process, application A\u0027s dependency cannot be\ncleared.\n\nThis leads to application A hanging indefinitely while waiting for a\ndependency that will never be resolved. Fix this issue by ensuring that\nscheduled fences are properly signaled when an entity is killed, allowing\ndependent applications to continue execution.",
"id": "GHSA-637r-5w8j-mjg6",
"modified": "2026-04-18T09:30:16Z",
"published": "2025-07-25T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38436"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/471db2c2d4f80ee94225a1ef246e4f5011733e50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8342127a8a65b0673863b106ce32b79c91ae3270"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa382a8b6ed483e9812d0e63b6d1bdcba0186f29"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aefd0a935625165a6ca36d0258d2d053901555df"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5734f9bab6f0d40577ad0633af4090a5fda2407"
}
],
"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-63CM-3458-95CR
Vulnerability from github – Published: 2024-03-25 12:30 – Updated: 2025-03-13 21:31In the Linux kernel, the following vulnerability has been resolved:
tipc: wait and exit until all work queues are done
On some host, a crash could be triggered simply by repeating these commands several times:
# modprobe tipc # tipc bearer enable media udp name UDP1 localip 127.0.0.1 # rmmod tipc
[] BUG: unable to handle kernel paging request at ffffffffc096bb00 [] Workqueue: events 0xffffffffc096bb00 [] Call Trace: [] ? process_one_work+0x1a7/0x360 [] ? worker_thread+0x30/0x390 [] ? create_worker+0x1a0/0x1a0 [] ? kthread+0x116/0x130 [] ? kthread_flush_work_fn+0x10/0x10 [] ? ret_from_fork+0x35/0x40
When removing the TIPC module, the UDP tunnel sock will be delayed to release in a work queue as sock_release() can't be done in rtnl_lock(). If the work queue is schedule to run after the TIPC module is removed, kernel will crash as the work queue function cleanup_beareri() code no longer exists when trying to invoke it.
To fix it, this patch introduce a member wq_count in tipc_net to track the numbers of work queues in schedule, and wait and exit until all work queues are done in tipc_exit_net().
{
"affected": [],
"aliases": [
"CVE-2021-47163"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-25T10:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: wait and exit until all work queues are done\n\nOn some host, a crash could be triggered simply by repeating these\ncommands several times:\n\n # modprobe tipc\n # tipc bearer enable media udp name UDP1 localip 127.0.0.1\n # rmmod tipc\n\n [] BUG: unable to handle kernel paging request at ffffffffc096bb00\n [] Workqueue: events 0xffffffffc096bb00\n [] Call Trace:\n [] ? process_one_work+0x1a7/0x360\n [] ? worker_thread+0x30/0x390\n [] ? create_worker+0x1a0/0x1a0\n [] ? kthread+0x116/0x130\n [] ? kthread_flush_work_fn+0x10/0x10\n [] ? ret_from_fork+0x35/0x40\n\nWhen removing the TIPC module, the UDP tunnel sock will be delayed to\nrelease in a work queue as sock_release() can\u0027t be done in rtnl_lock().\nIf the work queue is schedule to run after the TIPC module is removed,\nkernel will crash as the work queue function cleanup_beareri() code no\nlonger exists when trying to invoke it.\n\nTo fix it, this patch introduce a member wq_count in tipc_net to track\nthe numbers of work queues in schedule, and wait and exit until all\nwork queues are done in tipc_exit_net().",
"id": "GHSA-63cm-3458-95cr",
"modified": "2025-03-13T21:31:02Z",
"published": "2024-03-25T12:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47163"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04c26faa51d1e2fe71cf13c45791f5174c37f986"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5195ec5e365a2a9331bfeb585b613a6e94f98dba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9f5b7ad4ac3af006443f535b1ce7bff1d130d7d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d1f76dfadaf8f47ed1753f97dbcbd41c16215ffa"
}
],
"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-644J-VC34-VF98
Vulnerability from github – Published: 2026-04-13 15:31 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
bridge: mrp: reject zero test interval to avoid OOM panic
br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock.
The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames.
Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.
{
"affected": [],
"aliases": [
"CVE-2026-31420"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-13T14:16:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbridge: mrp: reject zero test interval to avoid OOM panic\n\nbr_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied\ninterval value from netlink without validation. When interval is 0,\nusecs_to_jiffies(0) yields 0, causing the delayed work\n(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule\nitself with zero delay. This creates a tight loop on system_percpu_wq\nthat allocates and transmits MRP test frames at maximum rate, exhausting\nall system memory and causing a kernel panic via OOM deadlock.\n\nThe same zero-interval issue applies to br_mrp_start_in_test_parse()\nfor interconnect test frames.\n\nUse NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both\nIFLA_BRIDGE_MRP_START_TEST_INTERVAL and\nIFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the\nnetlink attribute parsing layer before the value ever reaches the\nworkqueue scheduling code. This is consistent with how other bridge\nsubsystems (br_fdb, br_mst) enforce range constraints on netlink\nattributes.",
"id": "GHSA-644j-vc34-vf98",
"modified": "2026-06-01T18:31:23Z",
"published": "2026-04-13T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31420"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/630a15a31c2034b5b697f4aabc769b9d80d82446"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9bc352f716d1bebfe43354bce539ec2d0223b30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e8ec80430bfa520e7352155d6ac632e527cba7aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa6e24963342de4370e3a3c9af41e38277b74cf3"
}
],
"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-65R3-2H9P-MM4C
Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()
There is a deadlock in rtllib_beacons_stop(), which is shown below:
(Thread 1) | (Thread 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rtllib_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ...
We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, rtllib_beacons_stop() will block forever.
This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.
{
"affected": [],
"aliases": [
"CVE-2022-49315"
],
"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\ndrivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()\n\nThere is a deadlock in rtllib_beacons_stop(), which is shown\nbelow:\n\n (Thread 1) | (Thread 2)\n | rtllib_send_beacon()\nrtllib_beacons_stop() | mod_timer()\n spin_lock_irqsave() //(1) | (wait a time)\n ... | rtllib_send_beacon_cb()\n del_timer_sync() | spin_lock_irqsave() //(2)\n (wait timer to stop) | ...\n\nWe hold ieee-\u003ebeacon_lock in position (1) of thread 1 and\nuse del_timer_sync() to wait timer to stop, but timer handler\nalso need ieee-\u003ebeacon_lock in position (2) of thread 2.\nAs a result, rtllib_beacons_stop() will block forever.\n\nThis patch extracts del_timer_sync() from the protection of\nspin_lock_irqsave(), which could let timer handler to obtain\nthe needed lock.",
"id": "GHSA-65r3-2h9p-mm4c",
"modified": "2025-03-14T00:30:51Z",
"published": "2025-03-14T00:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49315"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08bacf871c019163ccd1389d0bc957a43324967a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f69d7d5e918aa43423d86bd17ddb11b1b5e8ada"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/381045dc64d23a2229c47c5524c06bfc33d34446"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4681129fda9e8555392eaaadb239ec6a6e2b3e12"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/46c861009bf437a18417df24cea0d181741b7d72"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64b05fa212c7e4d057676e8b7e7120c6eb2f615b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b6bdbd9337de3917945847bde262a34a87a6303"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fef451f0fbbe85dbd2962b18379d02e2965610db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffd4c4d5293e4985092ea45ba21cad9326e2e434"
}
],
"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-668P-X3M7-8W6V
Vulnerability from github – Published: 2024-01-17 18:31 – Updated: 2024-01-24 21:30A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel’s SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.
{
"affected": [],
"aliases": [
"CVE-2024-0639"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-833"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-17T16:15:46Z",
"severity": "MODERATE"
},
"details": "A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel\u2019s SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.",
"id": "GHSA-668p-x3m7-8w6v",
"modified": "2024-01-24T21:30:32Z",
"published": "2024-01-17T18:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0639"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/6feb37b3b06e9049e20dcf7e23998f92c9c5be9a"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-0639"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2258754"
}
],
"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-66MX-VW67-WMQ9
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
batman-adv: bypass empty buckets in batadv_purge_orig_ref()
Many syzbot reports are pointing to soft lockups in batadv_purge_orig_ref() [1]
Root cause is unknown, but we can avoid spending too much time there and perhaps get more interesting reports.
[1]
watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621] Modules linked in: irq event stamp: 6182794 hardirqs last enabled at (6182793): [] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 hardirqs last disabled at (6182794): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (6182794): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (6182792): [] spin_unlock_bh include/linux/spinlock.h:396 [inline] softirqs last enabled at (6182792): [] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 softirqs last disabled at (6182790): [] spin_lock_bh include/linux/spinlock.h:356 [inline] softirqs last disabled at (6182790): [] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271 CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: bat_events batadv_purge_orig pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline] pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388 lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 sp : ffff800099007970 x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000 x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001 x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4 x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0 x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001 x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000 Call trace: __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline] arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline] __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51 lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103 sp : ffff800093a17d30 x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4 x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002 x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000 x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396 x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-40981"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: bypass empty buckets in batadv_purge_orig_ref()\n\nMany syzbot reports are pointing to soft lockups in\nbatadv_purge_orig_ref() [1]\n\nRoot cause is unknown, but we can avoid spending too much\ntime there and perhaps get more interesting reports.\n\n[1]\n\nwatchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]\nModules linked in:\nirq event stamp: 6182794\n hardirqs last enabled at (6182793): [\u003cffff8000801dae10\u003e] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\n hardirqs last disabled at (6182794): [\u003cffff80008ad66a78\u003e] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (6182794): [\u003cffff80008ad66a78\u003e] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last enabled at (6182792): [\u003cffff80008aab71c4\u003e] spin_unlock_bh include/linux/spinlock.h:396 [inline]\n softirqs last enabled at (6182792): [\u003cffff80008aab71c4\u003e] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n softirqs last disabled at (6182790): [\u003cffff80008aab61dc\u003e] spin_lock_bh include/linux/spinlock.h:356 [inline]\n softirqs last disabled at (6182790): [\u003cffff80008aab61dc\u003e] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271\nCPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\nWorkqueue: bat_events batadv_purge_orig\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]\n pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388\n lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\nsp : ffff800099007970\nx29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000\nx26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001\nx23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4\nx20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0\nx17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001\nx14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003\nx11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000\nx2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000\nCall trace:\n __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]\n arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]\n __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386\n __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]\n _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210\n spin_unlock_bh include/linux/spinlock.h:396 [inline]\n batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300\n process_one_work+0x694/0x1204 kernel/workqueue.c:2633\n process_scheduled_works kernel/workqueue.c:2706 [inline]\n worker_thread+0x938/0xef4 kernel/workqueue.c:2787\n kthread+0x288/0x310 kernel/kthread.c:388\n ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860\nSending NMI from CPU 0 to CPUs 1:\nNMI backtrace for cpu 1\nCPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51\n lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103\nsp : ffff800093a17d30\nx29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4\nx26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002\nx23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000\nx20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396\nx17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001\n---truncated---",
"id": "GHSA-66mx-vw67-wmq9",
"modified": "2025-11-04T00:30:56Z",
"published": "2024-07-12T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40981"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/154e3f862ba33675cf3f4abf0a0a309a89df87d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2685008a5f9a636434a8508419cee8158a2f52c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/40dc8ab605894acae1473e434944924a22cfaaa0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/79636f636126775436a11ee9cf00a9253a33ac11"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82cdea8f3af1e36543c937df963d108c60bea030"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92176caf9896572f00e741a93cecc0ef1172da07"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae7f3cffe86aea3da0e8e079525a1ae619b8862a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fed7914858a1f1f3e6350bb0f620d6ef15107d16"
},
{
"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"
}
]
}
GHSA-674M-P5V7-MCQP
Vulnerability from github – Published: 2022-05-02 03:24 – Updated: 2024-02-15 21:31The ptrace_start function in kernel/ptrace.c in the Linux kernel 2.6.18 does not properly handle simultaneous execution of the do_coredump function, which allows local users to cause a denial of service (deadlock) via vectors involving the ptrace system call and a coredumping thread.
{
"affected": [],
"aliases": [
"CVE-2009-1388"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-07-05T16:30:00Z",
"severity": "MODERATE"
},
"details": "The ptrace_start function in kernel/ptrace.c in the Linux kernel 2.6.18 does not properly handle simultaneous execution of the do_coredump function, which allows local users to cause a denial of service (deadlock) via vectors involving the ptrace system call and a coredumping thread.",
"id": "GHSA-674m-p5v7-mcqp",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-05-02T03:24:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1388"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/attachment.cgi?id=346615"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/attachment.cgi?id=346742"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=504263"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A8625"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A8680"
},
{
"type": "WEB",
"url": "http://marc.info/?l=oss-security\u0026m=124654277229434\u0026w=2"
},
{
"type": "WEB",
"url": "http://osvdb.org/55679"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/36131"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/37471"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2009-1193.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/507985/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/35559"
},
{
"type": "WEB",
"url": "http://www.vmware.com/security/advisories/VMSA-2009-0016.html"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/3316"
}
],
"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.