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-CR25-MCG8-CFVP
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
scsi: megaraid_sas: Fix for a potential deadlock
This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex);
Fix this by temporarily releasing the reset_mutex.
{
"affected": [],
"aliases": [
"CVE-2024-57807"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: megaraid_sas: Fix for a potential deadlock\n\nThis fixes a \u0027possible circular locking dependency detected\u0027 warning\n CPU0 CPU1\n ---- ----\n lock(\u0026instance-\u003ereset_mutex);\n lock(\u0026shost-\u003escan_mutex);\n lock(\u0026instance-\u003ereset_mutex);\n lock(\u0026shost-\u003escan_mutex);\n\nFix this by temporarily releasing the reset_mutex.",
"id": "GHSA-cr25-mcg8-cfvp",
"modified": "2025-11-03T21:32:07Z",
"published": "2025-01-11T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57807"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c654998a3e8167a58b6c6fede545fe400a4b554"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/466ca39dbf5d0ba71c16b15c27478a9c7d4022a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/50740f4dc78b41dec7c8e39772619d5ba841ddd7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78afb9bfad00c4aa58a424111d7edbcab9452f2b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/edadc693bfcc0f1ea08b8fa041c9361fd042410d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f36d024bd15ed356a80dda3ddc46d0a62aa55815"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f50783148ec98a1d38b87422e2ceaf2380b7b606"
},
{
"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-CR4C-WW97-FPHQ
Vulnerability from github – Published: 2024-03-15 21:30 – Updated: 2025-03-13 21:31In the Linux kernel, the following vulnerability has been resolved:
bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks
Commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") added an implementation of the locked_down LSM hook to SELinux, with the aim to restrict which domains are allowed to perform operations that would breach lockdown. This is indirectly also getting audit subsystem involved to report events. The latter is problematic, as reported by Ondrej and Serhei, since it can bring down the whole system via audit:
1) The audit events that are triggered due to calls to security_locked_down() can OOM kill a machine, see below details [0].
2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit() when trying to wake up kauditd, for example, when using trace_sched_switch() tracepoint, see details in [1]. Triggering this was not via some hypothetical corner case, but with existing tools like runqlat & runqslower from bcc, for example, which make use of this tracepoint. Rough call sequence goes like:
rq_lock(rq) -> -------------------------+
trace_sched_switch() -> |
bpf_prog_xyz() -> +-> deadlock
selinux_lockdown() -> |
audit_log_end() -> |
wake_up_interruptible() -> |
try_to_wake_up() -> |
rq_lock(rq) --------------+
What's worse is that the intention of 59438b46471a to further restrict lockdown settings for specific applications in respect to the global lockdown policy is completely broken for BPF. The SELinux policy rule for the current lockdown check looks something like this:
allow : lockdown { };
However, this doesn't match with the 'current' task where the security_locked_down() is executed, example: httpd does a syscall. There is a tracing program attached to the syscall which triggers a BPF program to run, which ends up doing a bpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does the permission check against 'current', that is, httpd in this example. httpd has literally zero relation to this tracing program, and it would be nonsensical having to write an SELinux policy rule against httpd to let the tracing helper pass. The policy in this case needs to be against the entity that is installing the BPF program. For example, if bpftrace would generate a histogram of syscall counts by user space application:
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
bpftrace would then go and generate a BPF program from this internally. One way of doing it [for the sake of the example] could be to call bpf_get_current_task() helper and then access current->comm via one of bpf_probe_read_kernel{,str}() helpers. So the program itself has nothing to do with httpd or any other random app doing a syscall here. The BPF program _explicitly initiated the lockdown check. The allow/deny policy belongs in the context of bpftrace: meaning, you want to grant bpftrace access to use these helpers, but other tracers on the system like my_random_tracer not.
Therefore fix all three issues at the same time by taking a completely different approach for the security_locked_down() hook, that is, move the check into the program verification phase where we actually retrieve the BPF func proto. This also reliably gets the task (current) that is trying to install the BPF tracing program, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since we're moving this out of the BPF helper's fast-path which can be called several millions of times per second.
The check is then also in line with other security_locked_down() hooks in the system where the enforcement is performed at open/load time, for example, open_kcore() for /proc/kcore access or module_sig_check() for module signatures just to pick f ---truncated---
{
"affected": [],
"aliases": [
"CVE-2021-47128"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-15T21:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, lockdown, audit: Fix buggy SELinux lockdown permission checks\n\nCommit 59438b46471a (\"security,lockdown,selinux: implement SELinux lockdown\")\nadded an implementation of the locked_down LSM hook to SELinux, with the aim\nto restrict which domains are allowed to perform operations that would breach\nlockdown. This is indirectly also getting audit subsystem involved to report\nevents. The latter is problematic, as reported by Ondrej and Serhei, since it\ncan bring down the whole system via audit:\n\n 1) The audit events that are triggered due to calls to security_locked_down()\n can OOM kill a machine, see below details [0].\n\n 2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit()\n when trying to wake up kauditd, for example, when using trace_sched_switch()\n tracepoint, see details in [1]. Triggering this was not via some hypothetical\n corner case, but with existing tools like runqlat \u0026 runqslower from bcc, for\n example, which make use of this tracepoint. Rough call sequence goes like:\n\n rq_lock(rq) -\u003e -------------------------+\n trace_sched_switch() -\u003e |\n bpf_prog_xyz() -\u003e +-\u003e deadlock\n selinux_lockdown() -\u003e |\n audit_log_end() -\u003e |\n wake_up_interruptible() -\u003e |\n try_to_wake_up() -\u003e |\n rq_lock(rq) --------------+\n\nWhat\u0027s worse is that the intention of 59438b46471a to further restrict lockdown\nsettings for specific applications in respect to the global lockdown policy is\ncompletely broken for BPF. The SELinux policy rule for the current lockdown check\nlooks something like this:\n\n allow \u003cwho\u003e \u003cwho\u003e : lockdown { \u003creason\u003e };\n\nHowever, this doesn\u0027t match with the \u0027current\u0027 task where the security_locked_down()\nis executed, example: httpd does a syscall. There is a tracing program attached\nto the syscall which triggers a BPF program to run, which ends up doing a\nbpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does\nthe permission check against \u0027current\u0027, that is, httpd in this example. httpd\nhas literally zero relation to this tracing program, and it would be nonsensical\nhaving to write an SELinux policy rule against httpd to let the tracing helper\npass. The policy in this case needs to be against the entity that is installing\nthe BPF program. For example, if bpftrace would generate a histogram of syscall\ncounts by user space application:\n\n bpftrace -e \u0027tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }\u0027\n\nbpftrace would then go and generate a BPF program from this internally. One way\nof doing it [for the sake of the example] could be to call bpf_get_current_task()\nhelper and then access current-\u003ecomm via one of bpf_probe_read_kernel{,_str}()\nhelpers. So the program itself has nothing to do with httpd or any other random\napp doing a syscall here. The BPF program _explicitly initiated_ the lockdown\ncheck. The allow/deny policy belongs in the context of bpftrace: meaning, you\nwant to grant bpftrace access to use these helpers, but other tracers on the\nsystem like my_random_tracer _not_.\n\nTherefore fix all three issues at the same time by taking a completely different\napproach for the security_locked_down() hook, that is, move the check into the\nprogram verification phase where we actually retrieve the BPF func proto. This\nalso reliably gets the task (current) that is trying to install the BPF tracing\nprogram, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since\nwe\u0027re moving this out of the BPF helper\u0027s fast-path which can be called several\nmillions of times per second.\n\nThe check is then also in line with other security_locked_down() hooks in the\nsystem where the enforcement is performed at open/load time, for example,\nopen_kcore() for /proc/kcore access or module_sig_check() for module signatures\njust to pick f\n---truncated---",
"id": "GHSA-cr4c-ww97-fphq",
"modified": "2025-03-13T21:31:00Z",
"published": "2024-03-15T21:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47128"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/acc43fc6cf0d50612193813c5906a1ab9d433e1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff40e51043af63715ab413995ff46996ecf9583f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff5039ec75c83d2ed5b781dc7733420ee8c985fc"
}
],
"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-CRW3-PH9V-P9P3
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-04 18:30In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix locking in pdc_iodc_print() firmware call
Utilize pdc_lock spinlock to protect parallel modifications of the iodc_dbuf[] buffer, check length to prevent buffer overflow of iodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong indentings.
{
"affected": [],
"aliases": [
"CVE-2022-50518"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:35Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix locking in pdc_iodc_print() firmware call\n\nUtilize pdc_lock spinlock to protect parallel modifications of the\niodc_dbuf[] buffer, check length to prevent buffer overflow of\niodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong\nindentings.",
"id": "GHSA-crw3-ph9v-p9p3",
"modified": "2026-02-04T18:30:19Z",
"published": "2025-10-07T18:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50518"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04a603058e70b8b881bb7860b8bd649f931f2591"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/553bc5890ed96a8d006224c3a4673c47fee0d12a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7236aae5f81f3efbd93d0601e74fc05994bc2580"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CRW5-QP92-P6M7
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2024-09-09 18:30In the Linux kernel, the following vulnerability has been resolved:
f2fs: don't set RO when shutting down f2fs
Shutdown does not check the error of thaw_super due to readonly, which causes a deadlock like below.
f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread - bdev_freeze - freeze_super - f2fs_stop_checkpoint() - f2fs_handle_critical_error - sb_start_write - set RO - waiting - bdev_thaw - thaw_super_locked - return -EINVAL, if sb_rdonly() - f2fs_stop_discard_thread -> wait for kthread_stop(discard_thread);
{
"affected": [],
"aliases": [
"CVE-2024-40969"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: don\u0027t set RO when shutting down f2fs\n\nShutdown does not check the error of thaw_super due to readonly, which\ncauses a deadlock like below.\n\nf2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread\n - bdev_freeze\n - freeze_super\n - f2fs_stop_checkpoint()\n - f2fs_handle_critical_error - sb_start_write\n - set RO - waiting\n - bdev_thaw\n - thaw_super_locked\n - return -EINVAL, if sb_rdonly()\n - f2fs_stop_discard_thread\n -\u003e wait for kthread_stop(discard_thread);",
"id": "GHSA-crw5-qp92-p6m7",
"modified": "2024-09-09T18:30:29Z",
"published": "2024-07-12T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40969"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3bdb7f161697e2d5123b89fe1778ef17a44858e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f47ed3b284b38f235355e281f57dfa8fffcc6563"
}
],
"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-CW78-Q654-793W
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-10-31 21:30In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: Avoid use of GFP_KERNEL in atomic context
Using GFP_KERNEL in preemption disable context, causing below warning when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
[ 32.542271] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 [ 32.550883] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 [ 32.558707] preempt_count: 1, expected: 0 [ 32.562710] RCU nest depth: 0, expected: 0 [ 32.566800] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc2-00269-gae9dcb91c606 #7 [ 32.576188] Hardware name: Marvell CN106XX board (DT) [ 32.581232] Call trace: [ 32.583670] dump_backtrace.part.0+0xe0/0xf0 [ 32.587937] show_stack+0x18/0x30 [ 32.591245] dump_stack_lvl+0x68/0x84 [ 32.594900] dump_stack+0x18/0x34 [ 32.598206] __might_resched+0x12c/0x160 [ 32.602122] __might_sleep+0x48/0xa0 [ 32.605689] __kmem_cache_alloc_node+0x2b8/0x2e0 [ 32.610301] __kmalloc+0x58/0x190 [ 32.613610] otx2_sq_aura_pool_init+0x1a8/0x314 [ 32.618134] otx2_open+0x1d4/0x9d0
To avoid use of GFP_ATOMIC for memory allocation, disable preemption after all memory allocation is done.
{
"affected": [],
"aliases": [
"CVE-2023-53030"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: Avoid use of GFP_KERNEL in atomic context\n\nUsing GFP_KERNEL in preemption disable context, causing below warning\nwhen CONFIG_DEBUG_ATOMIC_SLEEP is enabled.\n\n[ 32.542271] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274\n[ 32.550883] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0\n[ 32.558707] preempt_count: 1, expected: 0\n[ 32.562710] RCU nest depth: 0, expected: 0\n[ 32.566800] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc2-00269-gae9dcb91c606 #7\n[ 32.576188] Hardware name: Marvell CN106XX board (DT)\n[ 32.581232] Call trace:\n[ 32.583670] dump_backtrace.part.0+0xe0/0xf0\n[ 32.587937] show_stack+0x18/0x30\n[ 32.591245] dump_stack_lvl+0x68/0x84\n[ 32.594900] dump_stack+0x18/0x34\n[ 32.598206] __might_resched+0x12c/0x160\n[ 32.602122] __might_sleep+0x48/0xa0\n[ 32.605689] __kmem_cache_alloc_node+0x2b8/0x2e0\n[ 32.610301] __kmalloc+0x58/0x190\n[ 32.613610] otx2_sq_aura_pool_init+0x1a8/0x314\n[ 32.618134] otx2_open+0x1d4/0x9d0\n\nTo avoid use of GFP_ATOMIC for memory allocation, disable preemption\nafter all memory allocation is done.",
"id": "GHSA-cw78-q654-793w",
"modified": "2025-10-31T21:30:52Z",
"published": "2025-03-27T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53030"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1eb57b87f106c90cee6b2a56a10f2e29c7a25f3e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2827c4eb429db64befdca11362e2b1c5f524f6ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87b93b678e95c7d93fe6a55b0e0fbda26d8c7760"
}
],
"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-CWR2-26GQ-V2XR
Vulnerability from github – Published: 2024-04-03 15:30 – Updated: 2025-03-17 18:31In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.
While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock.
In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail.
Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting.
Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device.
{
"affected": [],
"aliases": [
"CVE-2024-26696"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T15:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix hang in nilfs_lookup_dirty_data_buffers()\n\nSyzbot reported a hang issue in migrate_pages_batch() called by mbind()\nand nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.\n\nWhile migrate_pages_batch() locks a folio and waits for the writeback to\ncomplete, the log writer thread that should bring the writeback to\ncompletion picks up the folio being written back in\nnilfs_lookup_dirty_data_buffers() that it calls for subsequent log\ncreation and was trying to lock the folio. Thus causing a deadlock.\n\nIn the first place, it is unexpected that folios/pages in the middle of\nwriteback will be updated and become dirty. Nilfs2 adds a checksum to\nverify the validity of the log being written and uses it for recovery at\nmount, so data changes during writeback are suppressed. Since this is\nbroken, an unclean shutdown could potentially cause recovery to fail.\n\nInvestigation revealed that the root cause is that the wait for writeback\ncompletion in nilfs_page_mkwrite() is conditional, and if the backing\ndevice does not require stable writes, data may be modified without\nwaiting.\n\nFix these issues by making nilfs_page_mkwrite() wait for writeback to\nfinish regardless of the stable write requirement of the backing device.",
"id": "GHSA-cwr2-26gq-v2xr",
"modified": "2025-03-17T18:31:38Z",
"published": "2024-04-03T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26696"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38296afe3c6ee07319e01bb249aa4bb47c07b534"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca54475c34f7d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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-CWWG-93GV-4R7H
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers.
{
"affected": [],
"aliases": [
"CVE-2024-35806"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: fsl: qbman: Always disable interrupts when taking cgr_lock\n\nsmp_call_function_single disables IRQs when executing the callback. To\nprevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.\nThis is already done by qman_update_cgr and qman_delete_cgr; fix the\nother lockers.",
"id": "GHSA-cwwg-93gv-4r7h",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-17T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35806"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a62168653774c36398d65846a98034436ee66d03"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/af25c5180b2b1796342798f6c56fcfd12f5035bd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f8030430"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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-CWX4-F9X9-PQHH
Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-07-06 15:30In the Linux kernel, the following vulnerability has been resolved:
xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()
iptfs_destroy_state() calls hrtimer_cancel() while holding a spinlock that the timer callback also acquires, leading to an ABBA deadlock on SMP systems.
For the output timer (iptfs_timer): - iptfs_destroy_state() holds x->lock, calls hrtimer_cancel() - iptfs_delay_timer() callback takes x->lock
For the drop timer (drop_timer): - iptfs_destroy_state() holds drop_lock, calls hrtimer_cancel() - iptfs_drop_timer() callback takes drop_lock
Both timers use HRTIMER_MODE_REL_SOFT, so their callbacks run in softirq context. When hrtimer_cancel() is called for a soft timer that is currently executing on another CPU, hrtimer_cancel_wait_running() spins on softirq_expiry_lock -- the same lock held by the softirq running the callback. If the callback is blocked waiting for the spinlock held by the caller of hrtimer_cancel(), a circular dependency forms:
CPU 0: holds lock_A -> waits for softirq_expiry_lock CPU 1: holds softirq_expiry_lock -> waits for lock_A
Fix by calling hrtimer_cancel() before acquiring the respective locks. hrtimer_cancel() is safe to call without holding any lock and will wait for any in-progress callback to complete. For the output timer, the lock is still acquired afterwards to drain the packet queue. For the drop timer, the lock/unlock pair is removed entirely since it only existed to serialize with the timer callback, which hrtimer_cancel() already guarantees.
Found by source code audit.
{
"affected": [],
"aliases": [
"CVE-2026-53197"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T09:16:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()\n\niptfs_destroy_state() calls hrtimer_cancel() while holding a spinlock\nthat the timer callback also acquires, leading to an ABBA deadlock on\nSMP systems.\n\nFor the output timer (iptfs_timer):\n - iptfs_destroy_state() holds x-\u003elock, calls hrtimer_cancel()\n - iptfs_delay_timer() callback takes x-\u003elock\n\nFor the drop timer (drop_timer):\n - iptfs_destroy_state() holds drop_lock, calls hrtimer_cancel()\n - iptfs_drop_timer() callback takes drop_lock\n\nBoth timers use HRTIMER_MODE_REL_SOFT, so their callbacks run in softirq\ncontext. When hrtimer_cancel() is called for a soft timer that is\ncurrently executing on another CPU, hrtimer_cancel_wait_running() spins\non softirq_expiry_lock -- the same lock held by the softirq running the\ncallback. If the callback is blocked waiting for the spinlock held by\nthe caller of hrtimer_cancel(), a circular dependency forms:\n\n CPU 0: holds lock_A -\u003e waits for softirq_expiry_lock\n CPU 1: holds softirq_expiry_lock -\u003e waits for lock_A\n\nFix by calling hrtimer_cancel() before acquiring the respective locks.\nhrtimer_cancel() is safe to call without holding any lock and will wait\nfor any in-progress callback to complete. For the output timer, the\nlock is still acquired afterwards to drain the packet queue. For the\ndrop timer, the lock/unlock pair is removed entirely since it only\nexisted to serialize with the timer callback, which hrtimer_cancel()\nalready guarantees.\n\nFound by source code audit.",
"id": "GHSA-cwx4-f9x9-pqhh",
"modified": "2026-07-06T15:30:42Z",
"published": "2026-06-25T09:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53197"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/822b98d354e63e8249e85473c5f3c519f3c9cecc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a13ca53e47e500854a3b9ec18b5dc83acfec863e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c8a8a75b733467b00c08b91a38dbaf207a08ed6e"
}
],
"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-CX5C-HRVR-85GJ
Vulnerability from github – Published: 2024-05-01 15:30 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
media: usbtv: Remove useless locks in usbtv_video_free()
Remove locks calls in usbtv_video_free() because are useless and may led to a deadlock as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000 Also remove usbtv_stop() call since it will be called when unregistering the device.
Before 'c838530d230b' this issue would only be noticed if you disconnect while streaming and now it is noticeable even when disconnecting while not streaming.
[hverkuil: fix minor spelling mistake in log message]
{
"affected": [],
"aliases": [
"CVE-2024-27072"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T13:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: usbtv: Remove useless locks in usbtv_video_free()\n\nRemove locks calls in usbtv_video_free() because\nare useless and may led to a deadlock as reported here:\nhttps://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000\nAlso remove usbtv_stop() call since it will be called when\nunregistering the device.\n\nBefore \u0027c838530d230b\u0027 this issue would only be noticed if you\ndisconnect while streaming and now it is noticeable even when\ndisconnecting while not streaming.\n\n\n[hverkuil: fix minor spelling mistake in log message]",
"id": "GHSA-cx5c-hrvr-85gj",
"modified": "2026-05-12T12:31:45Z",
"published": "2024-05-01T15:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27072"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e7d82ebb86e94643bdb30b0b5b077ed27dce1c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ec4641df57cbdfdc51bb4959afcdbcf5003ddb9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/65e6a2773d655172143cc0b927cdc89549842895"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bdd82c47b22a8befd617b723098b2a41b77373c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5ed208d04acf06781d63d30f9fa991e8d609ebd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dea46e246ef0f98d89d59a4229157cd9ffb636bf"
},
{
"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-CX67-J66H-CM23
Vulnerability from github – Published: 2026-06-26 21:32 – Updated: 2026-07-06 21:30In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Resolve soft lockup issue when opening /dev/sgX
The parameter def_reserved_size defines the default buffer size reserved for each Sg_fd and should be restricted to a range between 0 and 1,048,576 (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the function sg_proc_write_dressz enforces this limit, it is possible to bypass it by directly modifying the module parameter as shown below, which then causes a soft lockup:
echo -1 > /sys/module/sg/parameters/def_reserved_size exec 4<> /dev/sg0
watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537] Modules loaded: CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134, PREEMPT disabled Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version 1.16.1-2.fc37 dated 04/01/2014 ... Call Trace:
sg_build_reserve+0x5c/0xa0 sg_add_sfp+0x168/0x270 sg_open+0x16e/0x340 chrdev_open+0xbe/0x230 do_dentry_open+0x175/0x480 vfs_open+0x34/0xf0 do_open+0x265/0x3d0 path_openat+0x110/0x290 do_filp_open+0xc3/0x170 do_sys_openat2+0x71/0xe0 __x64_sys_openat+0x6d/0xa0 do_syscall_64+0x62/0x310 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The fix is to use module_param_cb to validate and reject invalid values assigned to def_reserved_size.
{
"affected": [],
"aliases": [
"CVE-2026-53304"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-26T20:17:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Resolve soft lockup issue when opening /dev/sgX\n\nThe parameter def_reserved_size defines the default buffer size reserved\nfor each Sg_fd and should be restricted to a range between 0 and 1,048,576\n(see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the\nfunction sg_proc_write_dressz enforces this limit, it is possible to bypass\nit by directly modifying the module parameter as shown below, which then\ncauses a soft lockup:\n\necho -1 \u003e /sys/module/sg/parameters/def_reserved_size\nexec 4\u003c\u003e /dev/sg0\n\nwatchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537]\nModules loaded:\nCPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134,\nPREEMPT disabled\nHardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version\n1.16.1-2.fc37 dated 04/01/2014\n...\nCall Trace:\n\n sg_build_reserve+0x5c/0xa0\n sg_add_sfp+0x168/0x270\n sg_open+0x16e/0x340\n chrdev_open+0xbe/0x230\n do_dentry_open+0x175/0x480\n vfs_open+0x34/0xf0\n do_open+0x265/0x3d0\n path_openat+0x110/0x290\n do_filp_open+0xc3/0x170\n do_sys_openat2+0x71/0xe0\n __x64_sys_openat+0x6d/0xa0\n do_syscall_64+0x62/0x310\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe fix is to use module_param_cb to validate and reject invalid values\nassigned to def_reserved_size.",
"id": "GHSA-cx67-j66h-cm23",
"modified": "2026-07-06T21:30:25Z",
"published": "2026-06-26T21:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53304"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1afd963fcd963db0dc5d47df6dfcf010c9c4647e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d74e0654ac908c65a8f20373091826fe43b1363"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9676ca7b1ef31a3a65b3e61e7ce3b54ce7364202"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c47ccfb3d80dfed522ca06a5954ac97488d78c5a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5f4a211e82d04ccc1809311322c47023bbe66e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d06a310b45e153872033dd0cf19d5a2279121099"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe671d3c84ffb1b763d590c25195755adeaadaba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/feade299e932967de27519338d41de348fb5b061"
}
],
"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.