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-77MF-44MV-3M36
Vulnerability from github – Published: 2024-04-25 06:30 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path
The commit mutex should not be released during the critical section between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC worker could collect expired objects and get the released commit lock within the same GC sequence.
nf_tables_module_autoload() temporarily releases the mutex to load module dependencies, then it goes back to replay the transaction again. Move it at the end of the abort phase after nft_gc_seq_end() is called.
{
"affected": [],
"aliases": [
"CVE-2024-26925"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-25T06:15:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: release mutex after nft_gc_seq_end from abort path\n\nThe commit mutex should not be released during the critical section\nbetween nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC\nworker could collect expired objects and get the released commit lock\nwithin the same GC sequence.\n\nnf_tables_module_autoload() temporarily releases the mutex to load\nmodule dependencies, then it goes back to replay the transaction again.\nMove it at the end of the abort phase after nft_gc_seq_end() is called.",
"id": "GHSA-77mf-44mv-3m36",
"modified": "2026-05-12T12:31:41Z",
"published": "2024-04-25T06:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26925"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-354112.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d459e2ffb541841714839e8228b845458ed3b27"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cee2ff7f8cce12a63a0a23ffe27f08d99541494"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61ac7284346c32f9a8c8ceac56102f7914060428"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8038ee3c3e5b59bcd78467686db5270c68544e30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8d3a58af50e46167b6f1db47adadad03c0045dae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a34ba4bdeec0c3b629160497594908dc820110f1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb769ff4e281f751adcaf4f4445cbf30817be139"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/07/6"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/08/2"
}
],
"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-787P-86V4-HHFG
Vulnerability from github – Published: 2026-02-18 15:31 – Updated: 2026-03-18 18:31In the Linux kernel, the following vulnerability has been resolved:
riscv: trace: fix snapshot deadlock with sbi ecall
If sbi_ecall.c's functions are traceable,
echo "__sbi_ecall:snapshot" > /sys/kernel/tracing/set_ftrace_filter
may get the kernel into a deadlock.
(Functions in sbi_ecall.c are excluded from tracing if CONFIG_RISCV_ALTERNATIVE_EARLY is set.)
__sbi_ecall triggers a snapshot of the ringbuffer. The snapshot code raises an IPI interrupt, which results in another call to __sbi_ecall and another snapshot...
All it takes to get into this endless loop is one initial __sbi_ecall. On RISC-V systems without SSTC extension, the clock events in timer-riscv.c issue periodic sbi ecalls, making the problem easy to trigger.
Always exclude the sbi_ecall.c functions from tracing to fix the potential deadlock.
sbi ecalls can easiliy be logged via trace events, excluding ecall functions from function tracing is not a big limitation.
{
"affected": [],
"aliases": [
"CVE-2026-23217"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-18T15:18:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: trace: fix snapshot deadlock with sbi ecall\n\nIf sbi_ecall.c\u0027s functions are traceable,\n\necho \"__sbi_ecall:snapshot\" \u003e /sys/kernel/tracing/set_ftrace_filter\n\nmay get the kernel into a deadlock.\n\n(Functions in sbi_ecall.c are excluded from tracing if\nCONFIG_RISCV_ALTERNATIVE_EARLY is set.)\n\n__sbi_ecall triggers a snapshot of the ringbuffer. The snapshot code\nraises an IPI interrupt, which results in another call to __sbi_ecall\nand another snapshot...\n\nAll it takes to get into this endless loop is one initial __sbi_ecall.\nOn RISC-V systems without SSTC extension, the clock events in\ntimer-riscv.c issue periodic sbi ecalls, making the problem easy to\ntrigger.\n\nAlways exclude the sbi_ecall.c functions from tracing to fix the\npotential deadlock.\n\nsbi ecalls can easiliy be logged via trace events, excluding ecall\nfunctions from function tracing is not a big limitation.",
"id": "GHSA-787p-86v4-hhfg",
"modified": "2026-03-18T18:31:12Z",
"published": "2026-02-18T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23217"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0d7f5f0c9f05f1b6d4ee7110f15bef9c11f9df0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1f8285bc8e3508c1fde23b5205f1270215d4984"
}
],
"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-78H7-V2WQ-QPHC
Vulnerability from github – Published: 2022-05-17 00:35 – Updated: 2024-02-15 21:31The pfs_getextattr function in FreeBSD 7.x before 7.3-RELEASE and 8.x before 8.0-RC1 unlocks a mutex that was not previously locked, which allows local users to cause a denial of service (kernel panic), overwrite arbitrary memory locations, and possibly execute arbitrary code via vectors related to opening a file on a file system that uses pseudofs.
{
"affected": [],
"aliases": [
"CVE-2010-4210"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2010-11-22T12:54:00Z",
"severity": "HIGH"
},
"details": "The pfs_getextattr function in FreeBSD 7.x before 7.3-RELEASE and 8.x before 8.0-RC1 unlocks a mutex that was not previously locked, which allows local users to cause a denial of service (kernel panic), overwrite arbitrary memory locations, and possibly execute arbitrary code via vectors related to opening a file on a file system that uses pseudofs.",
"id": "GHSA-78h7-v2wq-qphc",
"modified": "2024-02-15T21:31:24Z",
"published": "2022-05-17T00:35:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-4210"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/63218"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/15206"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/42200"
},
{
"type": "WEB",
"url": "http://security.FreeBSD.org/advisories/FreeBSD-SA-10:09.pseudofs.asc"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id?1024724"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2010/2956"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-79HF-9RWH-4GV8
Vulnerability from github – Published: 2024-03-06 09:30 – Updated: 2024-12-12 15:31In the Linux kernel, the following vulnerability has been resolved:
wifi: rt2x00: restart beacon queue when hardware reset
When a hardware reset is triggered, all registers are reset, so all queues are forced to stop in hardware interface. However, mac80211 will not automatically stop the queue. If we don't manually stop the beacon queue, the queue will be deadlocked and unable to start again. This patch fixes the issue where Apple devices cannot connect to the AP after calling ieee80211_restart_hw().
{
"affected": [],
"aliases": [
"CVE-2023-52595"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-06T07:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rt2x00: restart beacon queue when hardware reset\n\nWhen a hardware reset is triggered, all registers are reset, so all\nqueues are forced to stop in hardware interface. However, mac80211\nwill not automatically stop the queue. If we don\u0027t manually stop the\nbeacon queue, the queue will be deadlocked and unable to start again.\nThis patch fixes the issue where Apple devices cannot connect to the\nAP after calling ieee80211_restart_hw().",
"id": "GHSA-79hf-9rwh-4gv8",
"modified": "2024-12-12T15:31:05Z",
"published": "2024-03-06T09:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52595"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04cfe4a5da57ab9358cdfadea22bcb37324aaf83"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4cc198580a7b93a36f5beb923f40f7ae27a3716c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69e905beca193125820c201ab3db4fb0e245124e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/739b3ccd9486dff04af95f9a890846d088a84957"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a11d965a218f0cd95b13fe44d0bcd8a20ce134a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e1f113b57ddd18274d7c83618deca25cc880bc48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fdb580ed05df8973aa5149cafa598c64bebcd0cb"
},
{
"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-7G87-HX7M-PPG8
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2026-05-12 15:31In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lock
When netpoll is enabled, calling pr_warn_once() while holding kmemleak_lock in mem_pool_alloc() can cause a deadlock due to lock inversion with the netconsole subsystem. This occurs because pr_warn_once() may trigger netpoll, which eventually leads to __alloc_skb() and back into kmemleak code, attempting to reacquire kmemleak_lock.
This is the path for the deadlock.
mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn_once() -> netconsole subsystem -> netpoll -> __alloc_skb -> __create_object -> raw_spin_lock_irqsave(&kmemleak_lock, flags);
Fix this by setting a flag and issuing the pr_warn_once() after kmemleak_lock is released.
{
"affected": [],
"aliases": [
"CVE-2025-39736"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:34Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lock\n\nWhen netpoll is enabled, calling pr_warn_once() while holding\nkmemleak_lock in mem_pool_alloc() can cause a deadlock due to lock\ninversion with the netconsole subsystem. This occurs because\npr_warn_once() may trigger netpoll, which eventually leads to\n__alloc_skb() and back into kmemleak code, attempting to reacquire\nkmemleak_lock.\n\nThis is the path for the deadlock.\n\nmem_pool_alloc()\n -\u003e raw_spin_lock_irqsave(\u0026kmemleak_lock, flags);\n -\u003e pr_warn_once()\n -\u003e netconsole subsystem\n\t -\u003e netpoll\n\t -\u003e __alloc_skb\n\t\t -\u003e __create_object\n\t\t -\u003e raw_spin_lock_irqsave(\u0026kmemleak_lock, flags);\n\nFix this by setting a flag and issuing the pr_warn_once() after\nkmemleak_lock is released.",
"id": "GHSA-7g87-hx7m-ppg8",
"modified": "2026-05-12T15:31:05Z",
"published": "2025-09-11T18:35:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39736"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08f70be5e406ce47c822f2dd11c1170ca259605b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1da95d3d4b7b1d380ebd87b71a61e7e6aed3265d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47b0f6d8f0d2be4d311a49e13d2fd5f152f492b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b0151e1d468eb2667c37b7af99b3c075072d334"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62879faa8efe8d8a9c7bf7606ee9c068012d7dac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a0854de00ce2ee27edf39037e7836ad580eb3350"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a181b228b37a6a5625dad2bb4265bb7abb673e9f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7b6ea0ede687e7460e593c5ea478f50aa41682a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f249d32bb54876b4b6c3ae071af8ddca77af390b"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-7GC8-CFFQ-4R9R
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-21 15:34In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix deadlock between devlink lock and esw->wq
esw->work_queue executes esw_functions_changed_event_handler -> esw_vfs_changed_event_handler and acquires the devlink lock.
.eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -> mlx5_devlink_eswitch_mode_set -> mlx5_eswitch_disable_locked -> mlx5_eswitch_event_handler_unregister -> flush_workqueue deadlocks when esw_vfs_changed_event_handler executes.
Fix that by no longer flushing the work to avoid the deadlock, and using a generation counter to keep track of work relevance. This avoids an old handler manipulating an esw that has undergone one or more mode changes: - the counter is incremented in mlx5_eswitch_event_handler_unregister. - the counter is read and passed to the ephemeral mlx5_host_work struct. - the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on. - mlx5_eswitch_cleanup does the final draining before destroying the wq.
No longer flushing the workqueue has the side effect of maybe no longer cancelling pending vport_change_handler work items, but that's ok since those are disabled elsewhere: - mlx5_eswitch_disable_locked disables the vport eq notifier. - mlx5_esw_vport_disable disarms the HW EQ notification and marks vport->enabled under state_lock to false to prevent pending vport handler from doing anything. - mlx5_eswitch_cleanup destroys the workqueue and makes sure all events are disabled/finished.
{
"affected": [],
"aliases": [
"CVE-2026-43468"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T15:16:59Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix deadlock between devlink lock and esw-\u003ewq\n\nesw-\u003ework_queue executes esw_functions_changed_event_handler -\u003e\nesw_vfs_changed_event_handler and acquires the devlink lock.\n\n.eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -\u003e\nmlx5_devlink_eswitch_mode_set -\u003e mlx5_eswitch_disable_locked -\u003e\nmlx5_eswitch_event_handler_unregister -\u003e flush_workqueue deadlocks\nwhen esw_vfs_changed_event_handler executes.\n\nFix that by no longer flushing the work to avoid the deadlock, and using\na generation counter to keep track of work relevance. This avoids an old\nhandler manipulating an esw that has undergone one or more mode changes:\n- the counter is incremented in mlx5_eswitch_event_handler_unregister.\n- the counter is read and passed to the ephemeral mlx5_host_work struct.\n- the work handler takes the devlink lock and bails out if the current\n generation is different than the one it was scheduled to operate on.\n- mlx5_eswitch_cleanup does the final draining before destroying the wq.\n\nNo longer flushing the workqueue has the side effect of maybe no longer\ncancelling pending vport_change_handler work items, but that\u0027s ok since\nthose are disabled elsewhere:\n- mlx5_eswitch_disable_locked disables the vport eq notifier.\n- mlx5_esw_vport_disable disarms the HW EQ notification and marks\n vport-\u003eenabled under state_lock to false to prevent pending vport\n handler from doing anything.\n- mlx5_eswitch_cleanup destroys the workqueue and makes sure all events\n are disabled/finished.",
"id": "GHSA-7gc8-cffq-4r9r",
"modified": "2026-05-21T15:34:02Z",
"published": "2026-05-08T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43468"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0de867f6e34eae6907b367fd152c55e61cb98608"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c7313cb41b1b427078440364d2f042c276a1c0b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a7838bebc38374f74baaf88bf2cf8d439a92923"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90e7e5d14d0bd25ffd019a3aa39d9f1c05fedbe1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/957d2a58f7f8ebcbdd0a85935e0d2675134b890d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aed763abf0e905b4b8d747d1ba9e172961572f57"
}
],
"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-7GWV-CXWW-6GGG
Vulnerability from github – Published: 2025-05-13 21:30 – Updated: 2025-05-13 21:30Improper locking in the Intel(R) Integrated Connectivity I/O interface (CNVi) for some Intel(R) Core™ Ultra Processors may allow an unauthenticated user to potentially enable escalation of privilege via physical access.
{
"affected": [],
"aliases": [
"CVE-2025-20047"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-13T21:16:05Z",
"severity": "MODERATE"
},
"details": "Improper locking in the Intel(R) Integrated Connectivity I/O interface (CNVi) for some Intel(R) Core\u2122 Ultra Processors may allow an unauthenticated user to potentially enable escalation of privilege via physical access.",
"id": "GHSA-7gwv-cxww-6ggg",
"modified": "2025-05-13T21:30:55Z",
"published": "2025-05-13T21:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20047"
},
{
"type": "WEB",
"url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01180.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:P/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-7H53-GHP8-M96V
Vulnerability from github – Published: 2024-04-28 15:30 – Updated: 2024-10-30 18:30In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: Fix BUG: sleeping function called from invalid context errors
gma_crtc_page_flip() was holding the event_lock spinlock while calling crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event on mode_set_base() errors.
Instead unlock it after setting gma_crtc->page_flip_event and on errors re-take the lock and clear gma_crtc->page_flip_event it it is still set.
This fixes the following WARN/stacktrace:
[ 512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870 [ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell [ 512.123031] preempt_count: 1, expected: 0 [ 512.123048] RCU nest depth: 0, expected: 0 [ 512.123066] INFO: lockdep is turned off. [ 512.123080] irq event stamp: 0 [ 512.123094] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 512.123134] hardirqs last disabled at (0): [] copy_process+0x9fc/0x1de0 [ 512.123176] softirqs last enabled at (0): [] copy_process+0x9fc/0x1de0 [ 512.123207] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 512.123233] Preemption disabled at: [ 512.123241] [<0000000000000000>] 0x0 [ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G W 5.19.0+ #1 [ 512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 512.123323] Call Trace: [ 512.123346] [ 512.123370] dump_stack_lvl+0x5b/0x77 [ 512.123412] __might_resched.cold+0xff/0x13a [ 512.123458] ww_mutex_lock+0x1e/0xa0 [ 512.123495] psb_gem_pin+0x2c/0x150 [gma500_gfx] [ 512.123601] gma_pipe_set_base+0x76/0x240 [gma500_gfx] [ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx] [ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0 [ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.123936] drm_ioctl_kernel+0xa1/0x150 [ 512.123984] drm_ioctl+0x21f/0x420 [ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.124070] ? rcu_read_lock_bh_held+0xb/0x60 [ 512.124104] ? lock_release+0x1ef/0x2d0 [ 512.124161] __x64_sys_ioctl+0x8d/0xd0 [ 512.124203] do_syscall_64+0x58/0x80 [ 512.124239] ? do_syscall_64+0x67/0x80 [ 512.124267] ? trace_hardirqs_on_prepare+0x55/0xe0 [ 512.124300] ? do_syscall_64+0x67/0x80 [ 512.124340] ? rcu_read_lock_sched_held+0x10/0x80 [ 512.124377] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 512.124411] RIP: 0033:0x7fcc4a70740f [ 512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 [ 512.124470] RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f [ 512.124524] RDX: 00007ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009 [ 512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034 [ 512.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0 [ 512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0 [ 512.124647]
{
"affected": [],
"aliases": [
"CVE-2022-48634"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-28T13:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/gma500: Fix BUG: sleeping function called from invalid context errors\n\ngma_crtc_page_flip() was holding the event_lock spinlock while calling\ncrtc_funcs-\u003emode_set_base() which takes ww_mutex.\n\nThe only reason to hold event_lock is to clear gma_crtc-\u003epage_flip_event\non mode_set_base() errors.\n\nInstead unlock it after setting gma_crtc-\u003epage_flip_event and on\nerrors re-take the lock and clear gma_crtc-\u003epage_flip_event it\nit is still set.\n\nThis fixes the following WARN/stacktrace:\n\n[ 512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870\n[ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell\n[ 512.123031] preempt_count: 1, expected: 0\n[ 512.123048] RCU nest depth: 0, expected: 0\n[ 512.123066] INFO: lockdep is turned off.\n[ 512.123080] irq event stamp: 0\n[ 512.123094] hardirqs last enabled at (0): [\u003c0000000000000000\u003e] 0x0\n[ 512.123134] hardirqs last disabled at (0): [\u003cffffffff8d0ec28c\u003e] copy_process+0x9fc/0x1de0\n[ 512.123176] softirqs last enabled at (0): [\u003cffffffff8d0ec28c\u003e] copy_process+0x9fc/0x1de0\n[ 512.123207] softirqs last disabled at (0): [\u003c0000000000000000\u003e] 0x0\n[ 512.123233] Preemption disabled at:\n[ 512.123241] [\u003c0000000000000000\u003e] 0x0\n[ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G W 5.19.0+ #1\n[ 512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013\n[ 512.123323] Call Trace:\n[ 512.123346] \u003cTASK\u003e\n[ 512.123370] dump_stack_lvl+0x5b/0x77\n[ 512.123412] __might_resched.cold+0xff/0x13a\n[ 512.123458] ww_mutex_lock+0x1e/0xa0\n[ 512.123495] psb_gem_pin+0x2c/0x150 [gma500_gfx]\n[ 512.123601] gma_pipe_set_base+0x76/0x240 [gma500_gfx]\n[ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx]\n[ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0\n[ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10\n[ 512.123936] drm_ioctl_kernel+0xa1/0x150\n[ 512.123984] drm_ioctl+0x21f/0x420\n[ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10\n[ 512.124070] ? rcu_read_lock_bh_held+0xb/0x60\n[ 512.124104] ? lock_release+0x1ef/0x2d0\n[ 512.124161] __x64_sys_ioctl+0x8d/0xd0\n[ 512.124203] do_syscall_64+0x58/0x80\n[ 512.124239] ? do_syscall_64+0x67/0x80\n[ 512.124267] ? trace_hardirqs_on_prepare+0x55/0xe0\n[ 512.124300] ? do_syscall_64+0x67/0x80\n[ 512.124340] ? rcu_read_lock_sched_held+0x10/0x80\n[ 512.124377] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 512.124411] RIP: 0033:0x7fcc4a70740f\n[ 512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 \u003c89\u003e c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00\n[ 512.124470] RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n[ 512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f\n[ 512.124524] RDX: 00007ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009\n[ 512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034\n[ 512.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0\n[ 512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0\n[ 512.124647] \u003c/TASK\u003e",
"id": "GHSA-7h53-ghp8-m96v",
"modified": "2024-10-30T18:30:45Z",
"published": "2024-04-28T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48634"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/63e37a79f7bd939314997e29c2f5a9f0ef184281"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a6ed7624bf4d0a32f2631e74828bca7b7bf15afd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5812807e416618477d1bb0049727ce8bb8292fd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5ae504c8623476e13032670f1a6d6344d53ec9b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-7H5P-3H8W-5629
Vulnerability from github – Published: 2024-11-09 12:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential deadlock with newly created symlinks
Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock.
This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem().
This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held:
Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.
{
"affected": [],
"aliases": [
"CVE-2024-50229"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-09T11:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix potential deadlock with newly created symlinks\n\nSyzbot reported that page_symlink(), called by nilfs_symlink(), triggers\nmemory reclamation involving the filesystem layer, which can result in\ncircular lock dependencies among the reader/writer semaphore\nnilfs-\u003ens_segctor_sem, s_writers percpu_rwsem (intwrite) and the\nfs_reclaim pseudo lock.\n\nThis is because after commit 21fc61c73c39 (\"don\u0027t put symlink bodies in\npagecache into highmem\"), the gfp flags of the page cache for symbolic\nlinks are overwritten to GFP_KERNEL via inode_nohighmem().\n\nThis is not a problem for symlinks read from the backing device, because\nthe __GFP_FS flag is dropped after inode_nohighmem() is called. However,\nwhen a new symlink is created with nilfs_symlink(), the gfp flags remain\noverwritten to GFP_KERNEL. Then, memory allocation called from\npage_symlink() etc. triggers memory reclamation including the FS layer,\nwhich may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can\ncause a deadlock if they are called while nilfs-\u003ens_segctor_sem is held:\n\nFix this issue by dropping the __GFP_FS flag from the page cache GFP flags\nof newly created symlinks in the same way that nilfs_new_inode() and\n__nilfs_read_inode() do, as a workaround until we adopt nofs allocation\nscope consistently or improve the locking constraints.",
"id": "GHSA-7h5p-3h8w-5629",
"modified": "2025-11-04T00:31:59Z",
"published": "2024-11-09T12:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50229"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1246d86e7bbde265761932c6e2dce28c69cdcb91"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/58c7f44c7b9e5ac7e3b1e5da2572ed7767a12f38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69548bb663fcb63f9ee0301be808a36b9d78dac3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9aa5d43ac4cace8fb9bd964ff6c23f599dc3cd24"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1686db1e59f8fc016c4c9361e2119dd206f479a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3a033e3ecd3471248d474ef263aadc0059e516a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c72e0df0b56c1166736dc8eb62070ebb12591447"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc38c596e648575ce58bfc31623a6506eda4b94a"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/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-7J47-MXWC-G3XP
Vulnerability from github – Published: 2024-08-21 03:31 – Updated: 2024-09-03 15:30In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix soft lockup under heavy CEQE load
CEQEs are handled in interrupt handler currently. This may cause the CPU core staying in interrupt context too long and lead to soft lockup under heavy load.
Handle CEQEs in BH workqueue and set an upper limit for the number of CEQE handled by a single call of work handler.
{
"affected": [],
"aliases": [
"CVE-2024-43872"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T01:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix soft lockup under heavy CEQE load\n\nCEQEs are handled in interrupt handler currently. This may cause the\nCPU core staying in interrupt context too long and lead to soft lockup\nunder heavy load.\n\nHandle CEQEs in BH workqueue and set an upper limit for the number of\nCEQE handled by a single call of work handler.",
"id": "GHSA-7j47-mxwc-g3xp",
"modified": "2024-09-03T15:30:39Z",
"published": "2024-08-21T03:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43872"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06580b33c183c9f98e2a2ca96a86137179032c08"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2fdf34038369c0a27811e7b4680662a14ada1d6b"
}
],
"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.