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-X465-6XX8-6H3C
Vulnerability from github – Published: 2025-08-22 18:31 – Updated: 2026-01-07 18:30In the Linux kernel, the following vulnerability has been resolved:
hfsplus: remove mutex_lock check in hfsplus_free_extents
Syzbot reported an issue in hfsplus filesystem:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 hfsplus_free_extents+0x700/0xad0 Call Trace: hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606 hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56 cont_expand_zero fs/buffer.c:2383 [inline] cont_write_begin+0x2cf/0x860 fs/buffer.c:2446 hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52 generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347 hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263 notify_change+0xe38/0x10f0 fs/attr.c:420 do_truncate+0x1fb/0x2e0 fs/open.c:65 do_sys_ftruncate+0x2eb/0x380 fs/open.c:193 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock on file truncation") unlock extree before hfsplus_free_extents(), and add check wheather extree is locked in hfsplus_free_extents().
However, when operations such as hfsplus_file_release, hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed concurrently in different files, it is very likely to trigger the WARN_ON, which will lead syzbot and xfstest to consider it as an abnormality.
The comment above this warning also describes one of the easy triggering situations, which can easily trigger and cause xfstest&syzbot to report errors.
[task A] [task B] ->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock ->hfsplus_write_begin ->hfsplus_get_block ->hfsplus_file_extend ->hfsplus_ext_read_extent ->hfs_find_init ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!!
Several threads could try to lock the shared extents tree. And warning can be triggered in one thread when another thread has locked the tree. This is the wrong behavior of the code and we need to remove the warning.
{
"affected": [],
"aliases": [
"CVE-2025-38650"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-22T16:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: remove mutex_lock check in hfsplus_free_extents\n\nSyzbot reported an issue in hfsplus filesystem:\n\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346\n\thfsplus_free_extents+0x700/0xad0\nCall Trace:\n\u003cTASK\u003e\nhfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606\nhfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56\ncont_expand_zero fs/buffer.c:2383 [inline]\ncont_write_begin+0x2cf/0x860 fs/buffer.c:2446\nhfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52\ngeneric_cont_expand_simple+0x151/0x250 fs/buffer.c:2347\nhfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263\nnotify_change+0xe38/0x10f0 fs/attr.c:420\ndo_truncate+0x1fb/0x2e0 fs/open.c:65\ndo_sys_ftruncate+0x2eb/0x380 fs/open.c:193\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nTo avoid deadlock, Commit 31651c607151 (\"hfsplus: avoid deadlock\non file truncation\") unlock extree before hfsplus_free_extents(),\nand add check wheather extree is locked in hfsplus_free_extents().\n\nHowever, when operations such as hfsplus_file_release,\nhfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed\nconcurrently in different files, it is very likely to trigger the\nWARN_ON, which will lead syzbot and xfstest to consider it as an\nabnormality.\n\nThe comment above this warning also describes one of the easy\ntriggering situations, which can easily trigger and cause\nxfstest\u0026syzbot to report errors.\n\n[task A]\t\t\t[task B]\n-\u003ehfsplus_file_release\n -\u003ehfsplus_file_truncate\n -\u003ehfs_find_init\n -\u003emutex_lock\n -\u003emutex_unlock\n\t\t\t\t-\u003ehfsplus_write_begin\n\t\t\t\t -\u003ehfsplus_get_block\n\t\t\t\t -\u003ehfsplus_file_extend\n\t\t\t\t -\u003ehfsplus_ext_read_extent\n\t\t\t\t -\u003ehfs_find_init\n\t\t\t\t\t -\u003emutex_lock\n -\u003ehfsplus_free_extents\n WARN_ON(mutex_is_locked) !!!\n\nSeveral threads could try to lock the shared extents tree.\nAnd warning can be triggered in one thread when another thread\nhas locked the tree. This is the wrong behavior of the code and\nwe need to remove the warning.",
"id": "GHSA-x465-6xx8-6h3c",
"modified": "2026-01-07T18:30:21Z",
"published": "2025-08-22T18:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38650"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0807e4ac59a546f2346961c5e26a98901594b205"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/084933961ecda7561dedfb78c4676ccb90c91ada"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/14922f0cc92e010b160121679c0a6ca072f4e975"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/314310166ba1fdff7660dfd9d18ea42d7058f7ae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5055b7db94110f228961dea6b74eed0a93a50b01"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9764b8bb9f5f94df105cd2ac43829dd0d2c82b9f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a19ce9230b22a0866313932e7964cf05557a6008"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcb96956c921f1aae7e7b477f2435c56f77a31b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fdd6aca652122d6e97787e88d7dd53ddc8b74e7e"
},
{
"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-X4V6-W9V4-P32J
Vulnerability from github – Published: 2024-01-17 18:31 – Updated: 2024-01-24 21:30A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel’s TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.
{
"affected": [],
"aliases": [
"CVE-2024-0641"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-833"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-17T16:15:47Z",
"severity": "MODERATE"
},
"details": "A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel\u2019s TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.",
"id": "GHSA-x4v6-w9v4-p32j",
"modified": "2024-01-24T21:30:32Z",
"published": "2024-01-17T18:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0641"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/08e50cf071847323414df0835109b6f3560d44f5"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-0641"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2258757"
}
],
"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-X4W2-GH57-R677
Vulnerability from github – Published: 2025-03-12 12:30 – Updated: 2025-03-13 18:32In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix deadlock when freeing cgroup storage
The following commit bc235cdb423a ("bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]") first introduced deadlock prevention for fentry/fexit programs attaching on bpf_task_storage helpers. That commit also employed the logic in map free path in its v6 version.
Later bpf_cgrp_storage was first introduced in c4bcfb38a95e ("bpf: Implement cgroup storage available to non-cgroup-attached bpf progs") which faces the same issue as bpf_task_storage, instead of its busy counter, NULL was passed to bpf_local_storage_map_free() which opened a window to cause deadlock:
<TASK>
(acquiring local_storage->lock)
_raw_spin_lock_irqsave+0x3d/0x50
bpf_local_storage_update+0xd1/0x460
bpf_cgrp_storage_get+0x109/0x130
bpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170
? __bpf_prog_enter_recur+0x16/0x80
bpf_trampoline_6442485186+0x43/0xa4
cgroup_storage_ptr+0x9/0x20
(holding local_storage->lock)
bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160
bpf_selem_unlink_storage+0x6f/0x110
bpf_local_storage_map_free+0xa2/0x110
bpf_map_free_deferred+0x5b/0x90
process_one_work+0x17c/0x390
worker_thread+0x251/0x360
kthread+0xd2/0x100
ret_from_fork+0x34/0x50
ret_from_fork_asm+0x1a/0x30
</TASK>
Progs: - A: SEC("fentry/cgroup_storage_ptr") - cgid (BPF_MAP_TYPE_HASH) Record the id of the cgroup the current task belonging to in this hash map, using the address of the cgroup as the map key. - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE) If current task is a kworker, lookup the above hash map using function parameter @owner as the key to get its corresponding cgroup id which is then used to get a trusted pointer to the cgroup through bpf_cgroup_from_id(). This trusted pointer can then be passed to bpf_cgrp_storage_get() to finally trigger the deadlock issue. - B: SEC("tp_btf/sys_enter") - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE) The only purpose of this prog is to fill Prog A's hash map by calling bpf_cgrp_storage_get() for as many userspace tasks as possible.
Steps to reproduce: - Run A; - while (true) { Run B; Destroy B; }
Fix this issue by passing its busy counter to the free procedure so it can be properly incremented before storage/smap locking.
{
"affected": [],
"aliases": [
"CVE-2024-58088"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-12T10:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix deadlock when freeing cgroup storage\n\nThe following commit\nbc235cdb423a (\"bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]\")\nfirst introduced deadlock prevention for fentry/fexit programs attaching\non bpf_task_storage helpers. That commit also employed the logic in map\nfree path in its v6 version.\n\nLater bpf_cgrp_storage was first introduced in\nc4bcfb38a95e (\"bpf: Implement cgroup storage available to non-cgroup-attached bpf progs\")\nwhich faces the same issue as bpf_task_storage, instead of its busy\ncounter, NULL was passed to bpf_local_storage_map_free() which opened\na window to cause deadlock:\n\n\t\u003cTASK\u003e\n\t\t(acquiring local_storage-\u003elock)\n\t_raw_spin_lock_irqsave+0x3d/0x50\n\tbpf_local_storage_update+0xd1/0x460\n\tbpf_cgrp_storage_get+0x109/0x130\n\tbpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170\n\t? __bpf_prog_enter_recur+0x16/0x80\n\tbpf_trampoline_6442485186+0x43/0xa4\n\tcgroup_storage_ptr+0x9/0x20\n\t\t(holding local_storage-\u003elock)\n\tbpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160\n\tbpf_selem_unlink_storage+0x6f/0x110\n\tbpf_local_storage_map_free+0xa2/0x110\n\tbpf_map_free_deferred+0x5b/0x90\n\tprocess_one_work+0x17c/0x390\n\tworker_thread+0x251/0x360\n\tkthread+0xd2/0x100\n\tret_from_fork+0x34/0x50\n\tret_from_fork_asm+0x1a/0x30\n\t\u003c/TASK\u003e\n\nProgs:\n - A: SEC(\"fentry/cgroup_storage_ptr\")\n - cgid (BPF_MAP_TYPE_HASH)\n\tRecord the id of the cgroup the current task belonging\n\tto in this hash map, using the address of the cgroup\n\tas the map key.\n - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE)\n\tIf current task is a kworker, lookup the above hash\n\tmap using function parameter @owner as the key to get\n\tits corresponding cgroup id which is then used to get\n\ta trusted pointer to the cgroup through\n\tbpf_cgroup_from_id(). This trusted pointer can then\n\tbe passed to bpf_cgrp_storage_get() to finally trigger\n\tthe deadlock issue.\n - B: SEC(\"tp_btf/sys_enter\")\n - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE)\n\tThe only purpose of this prog is to fill Prog A\u0027s\n\thash map by calling bpf_cgrp_storage_get() for as\n\tmany userspace tasks as possible.\n\nSteps to reproduce:\n - Run A;\n - while (true) { Run B; Destroy B; }\n\nFix this issue by passing its busy counter to the free procedure so\nit can be properly incremented before storage/smap locking.",
"id": "GHSA-x4w2-gh57-r677",
"modified": "2025-03-13T18:32:20Z",
"published": "2025-03-12T12:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58088"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6ecb9fa14eec5f15d97c84c36896871335f6ddfb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c78f4afbd962f43a3989f45f3ca04300252b19b5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fac674d2bd68f3479f27328626b42d1eebd11fef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcec95b4ab3e7bc6b2f36e5d59f7e24104ea87f7"
}
],
"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-X5CV-7H6W-46HM
Vulnerability from github – Published: 2026-04-03 15:30 – Updated: 2026-04-24 15:32In the Linux kernel, the following vulnerability has been resolved:
wifi: wlcore: Fix a locking bug
Make sure that wl->mutex is locked before it is unlocked. This has been detected by the Clang thread-safety analyzer.
{
"affected": [],
"aliases": [
"CVE-2026-23420"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-03T14:16:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wlcore: Fix a locking bug\n\nMake sure that wl-\u003emutex is locked before it is unlocked. This has been\ndetected by the Clang thread-safety analyzer.",
"id": "GHSA-x5cv-7h6w-46hm",
"modified": "2026-04-24T15:32:21Z",
"published": "2026-04-03T15:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23420"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1a1c28a08d74716f3f8e3a21c86b30d0ff13521a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ae8faf31b24c78653f4433298ee52813a56967a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5feeea59ed142e15c3284d0b1a364c6786bf3487"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72c6df8f284b3a49812ce2ac136727ace70acc7c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7ab511003c5ae3bf5364d7699a2e3ab1db513680"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aca4c9e4901b01b8b985993dc7df80bd1d1338bd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc404390a386404cf9822d4091ccae1f61efcbcd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcef983ad88832f3aa83491a174c345de57afbbd"
}
],
"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-X5FC-MWCH-J73R
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
mwifiex: bring down link before deleting interface
We can deadlock when rmmod'ing the driver or going through firmware reset, because the cfg80211_unregister_wdev() has to bring down the link for us, ... which then grab the same wiphy lock.
nl80211_del_interface() already handles a very similar case, with a nice description:
/*
* We hold RTNL, so this is safe, without RTNL opencount cannot
* reach 0, and thus the rdev cannot be deleted.
*
* We need to do it for the dev_close(), since that will call
* the netdev notifiers, and we need to acquire the mutex there
* but don't know if we get there from here or from some other
* place (e.g. "ip link set ... down").
*/
mutex_unlock(&rdev->wiphy.mtx);
...
Do similarly for mwifiex teardown, by ensuring we bring the link down first.
Sample deadlock trace:
[ 247.103516] INFO: task rmmod:2119 blocked for more than 123 seconds. [ 247.110630] Not tainted 5.12.4 #5 [ 247.115796] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 247.124557] task:rmmod state:D stack: 0 pid: 2119 ppid: 2114 flags:0x00400208 [ 247.133905] Call trace: [ 247.136644] __switch_to+0x130/0x170 [ 247.140643] __schedule+0x714/0xa0c [ 247.144548] schedule_preempt_disabled+0x88/0xf4 [ 247.149714] __mutex_lock_common+0x43c/0x750 [ 247.154496] mutex_lock_nested+0x5c/0x68 [ 247.158884] cfg80211_netdev_notifier_call+0x280/0x4e0 [cfg80211] [ 247.165769] raw_notifier_call_chain+0x4c/0x78 [ 247.170742] call_netdevice_notifiers_info+0x68/0xa4 [ 247.176305] __dev_close_many+0x7c/0x138 [ 247.180693] dev_close_many+0x7c/0x10c [ 247.184893] unregister_netdevice_many+0xfc/0x654 [ 247.190158] unregister_netdevice_queue+0xb4/0xe0 [ 247.195424] _cfg80211_unregister_wdev+0xa4/0x204 [cfg80211] [ 247.201816] cfg80211_unregister_wdev+0x20/0x2c [cfg80211] [ 247.208016] mwifiex_del_virtual_intf+0xc8/0x188 [mwifiex] [ 247.214174] mwifiex_uninit_sw+0x158/0x1b0 [mwifiex] [ 247.219747] mwifiex_remove_card+0x38/0xa0 [mwifiex] [ 247.225316] mwifiex_pcie_remove+0xd0/0xe0 [mwifiex_pcie] [ 247.231451] pci_device_remove+0x50/0xe0 [ 247.235849] device_release_driver_internal+0x110/0x1b0 [ 247.241701] driver_detach+0x5c/0x9c [ 247.245704] bus_remove_driver+0x84/0xb8 [ 247.250095] driver_unregister+0x3c/0x60 [ 247.254486] pci_unregister_driver+0x2c/0x90 [ 247.259267] cleanup_module+0x18/0xcdc [mwifiex_pcie]
{
"affected": [],
"aliases": [
"CVE-2021-47349"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmwifiex: bring down link before deleting interface\n\nWe can deadlock when rmmod\u0027ing the driver or going through firmware\nreset, because the cfg80211_unregister_wdev() has to bring down the link\nfor us, ... which then grab the same wiphy lock.\n\nnl80211_del_interface() already handles a very similar case, with a nice\ndescription:\n\n /*\n * We hold RTNL, so this is safe, without RTNL opencount cannot\n * reach 0, and thus the rdev cannot be deleted.\n *\n * We need to do it for the dev_close(), since that will call\n * the netdev notifiers, and we need to acquire the mutex there\n * but don\u0027t know if we get there from here or from some other\n * place (e.g. \"ip link set ... down\").\n */\n mutex_unlock(\u0026rdev-\u003ewiphy.mtx);\n...\n\nDo similarly for mwifiex teardown, by ensuring we bring the link down\nfirst.\n\nSample deadlock trace:\n\n[ 247.103516] INFO: task rmmod:2119 blocked for more than 123 seconds.\n[ 247.110630] Not tainted 5.12.4 #5\n[ 247.115796] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 247.124557] task:rmmod state:D stack: 0 pid: 2119 ppid: 2114 flags:0x00400208\n[ 247.133905] Call trace:\n[ 247.136644] __switch_to+0x130/0x170\n[ 247.140643] __schedule+0x714/0xa0c\n[ 247.144548] schedule_preempt_disabled+0x88/0xf4\n[ 247.149714] __mutex_lock_common+0x43c/0x750\n[ 247.154496] mutex_lock_nested+0x5c/0x68\n[ 247.158884] cfg80211_netdev_notifier_call+0x280/0x4e0 [cfg80211]\n[ 247.165769] raw_notifier_call_chain+0x4c/0x78\n[ 247.170742] call_netdevice_notifiers_info+0x68/0xa4\n[ 247.176305] __dev_close_many+0x7c/0x138\n[ 247.180693] dev_close_many+0x7c/0x10c\n[ 247.184893] unregister_netdevice_many+0xfc/0x654\n[ 247.190158] unregister_netdevice_queue+0xb4/0xe0\n[ 247.195424] _cfg80211_unregister_wdev+0xa4/0x204 [cfg80211]\n[ 247.201816] cfg80211_unregister_wdev+0x20/0x2c [cfg80211]\n[ 247.208016] mwifiex_del_virtual_intf+0xc8/0x188 [mwifiex]\n[ 247.214174] mwifiex_uninit_sw+0x158/0x1b0 [mwifiex]\n[ 247.219747] mwifiex_remove_card+0x38/0xa0 [mwifiex]\n[ 247.225316] mwifiex_pcie_remove+0xd0/0xe0 [mwifiex_pcie]\n[ 247.231451] pci_device_remove+0x50/0xe0\n[ 247.235849] device_release_driver_internal+0x110/0x1b0\n[ 247.241701] driver_detach+0x5c/0x9c\n[ 247.245704] bus_remove_driver+0x84/0xb8\n[ 247.250095] driver_unregister+0x3c/0x60\n[ 247.254486] pci_unregister_driver+0x2c/0x90\n[ 247.259267] cleanup_module+0x18/0xcdc [mwifiex_pcie]",
"id": "GHSA-x5fc-mwch-j73r",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-21T15:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47349"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f9482aa8d412b4ba06ce6ab8e333fb8ca29a06e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35af69c7c0490fdccfc159c6a87e4d1dc070838a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3041d39d3c14da97fa3476835aba043ba810cf0"
}
],
"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-X5VM-26PP-XFF5
Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: lock the inode in shared mode before starting fiemap
Currently fiemap does not take the inode's lock (VFS lock), it only locks a file range in the inode's io tree. This however can lead to a deadlock if we have a concurrent fsync on the file and fiemap code triggers a fault when accessing the user space buffer with fiemap_fill_next_extent(). The deadlock happens on the inode's i_mmap_lock semaphore, which is taken both by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by syzbot and triggers a trace like the following:
task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [inline] wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [inline] filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline] start_ordered_ops fs/btrfs/file.c:1737 [inline] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs.h:2885 [inline] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 INFO: task syz-executor361:5697 blocked for more than 145 seconds. Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [inline] __handle_mm_fault mm/memory.c:5073 [inline] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [inline] exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233 Code: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-52737"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T16:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: lock the inode in shared mode before starting fiemap\n\nCurrently fiemap does not take the inode\u0027s lock (VFS lock), it only locks\na file range in the inode\u0027s io tree. This however can lead to a deadlock\nif we have a concurrent fsync on the file and fiemap code triggers a fault\nwhen accessing the user space buffer with fiemap_fill_next_extent(). The\ndeadlock happens on the inode\u0027s i_mmap_lock semaphore, which is taken both\nby fsync and btrfs_page_mkwrite(). This deadlock was recently reported by\nsyzbot and triggers a trace like the following:\n\n task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004\n Call Trace:\n \u003cTASK\u003e\n context_switch kernel/sched/core.c:5293 [inline]\n __schedule+0x995/0xe20 kernel/sched/core.c:6606\n schedule+0xcb/0x190 kernel/sched/core.c:6682\n wait_on_state fs/btrfs/extent-io-tree.c:707 [inline]\n wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751\n lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742\n find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488\n writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863\n __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174\n extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091\n extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211\n do_writepages+0x3c3/0x680 mm/page-writeback.c:2581\n filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388\n __filemap_fdatawrite_range mm/filemap.c:421 [inline]\n filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439\n btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline]\n start_ordered_ops fs/btrfs/file.c:1737 [inline]\n btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839\n generic_write_sync include/linux/fs.h:2885 [inline]\n btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684\n call_write_iter include/linux/fs.h:2189 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x7dc/0xc50 fs/read_write.c:584\n ksys_write+0x177/0x2a0 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0033:0x7f7d4054e9b9\n RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9\n RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006\n RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69\n R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8\n \u003c/TASK\u003e\n INFO: task syz-executor361:5697 blocked for more than 145 seconds.\n Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004\n Call Trace:\n \u003cTASK\u003e\n context_switch kernel/sched/core.c:5293 [inline]\n __schedule+0x995/0xe20 kernel/sched/core.c:6606\n schedule+0xcb/0x190 kernel/sched/core.c:6682\n rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095\n __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260\n btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526\n do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947\n wp_page_shared+0x15e/0x380 mm/memory.c:3295\n handle_pte_fault mm/memory.c:4949 [inline]\n __handle_mm_fault mm/memory.c:5073 [inline]\n handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219\n do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428\n handle_page_fault arch/x86/mm/fault.c:1519 [inline]\n exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575\n asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570\n RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233\n Code: 74 0a 89 (...)\n RSP: 0018:ffffc9000570f330 EFLAGS: 000502\n---truncated---",
"id": "GHSA-x5vm-26pp-xff5",
"modified": "2026-06-01T18:31:18Z",
"published": "2024-05-21T18:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52737"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/519b7e13b5ae8dd38da1e52275705343be6bb508"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8c594da79bc0244e610a70594e824a401802be1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e425191073a80906d8502b5179471cc58b0b9e9a"
}
],
"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-X63M-J7X3-7J84
Vulnerability from github – Published: 2024-12-29 12:30 – Updated: 2025-01-08 00:30In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()
syzbot reports deadlock issue of f2fs as below:
====================================================== WARNING: possible circular locking dependency detected 6.12.0-rc3-syzkaller-00087-gc964ced77262 #0 Not tainted
kswapd0/79 is trying to acquire lock: ffff888011824088 (&sbi->sb_lock){++++}-{3:3}, at: f2fs_down_write fs/f2fs/f2fs.h:2199 [inline] ffff888011824088 (&sbi->sb_lock){++++}-{3:3}, at: f2fs_record_stop_reason+0x52/0x1d0 fs/f2fs/super.c:4068
but task is already holding lock: ffff88804bd92610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (sb_internal#2){.+.+}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 percpu_down_read include/linux/percpu-rwsem.h:51 [inline] __sb_start_write include/linux/fs.h:1716 [inline] sb_start_intwrite+0x4d/0x1c0 include/linux/fs.h:1899 f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842 evict+0x4e8/0x9b0 fs/inode.c:725 f2fs_evict_inode+0x1a4/0x15c0 fs/f2fs/inode.c:807 evict+0x4e8/0x9b0 fs/inode.c:725 dispose_list fs/inode.c:774 [inline] prune_icache_sb+0x239/0x2f0 fs/inode.c:963 super_cache_scan+0x38c/0x4b0 fs/super.c:223 do_shrink_slab+0x701/0x1160 mm/shrinker.c:435 shrink_slab+0x1093/0x14d0 mm/shrinker.c:662 shrink_one+0x43b/0x850 mm/vmscan.c:4818 shrink_many mm/vmscan.c:4879 [inline] lru_gen_shrink_node mm/vmscan.c:4957 [inline] shrink_node+0x3799/0x3de0 mm/vmscan.c:5937 kswapd_shrink_node mm/vmscan.c:6765 [inline] balance_pgdat mm/vmscan.c:6957 [inline] kswapd+0x1ca3/0x3700 mm/vmscan.c:7226 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
-> #1 (fs_reclaim){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __fs_reclaim_acquire mm/page_alloc.c:3834 [inline] fs_reclaim_acquire+0x88/0x130 mm/page_alloc.c:3848 might_alloc include/linux/sched/mm.h:318 [inline] prepare_alloc_pages+0x147/0x5b0 mm/page_alloc.c:4493 __alloc_pages_noprof+0x16f/0x710 mm/page_alloc.c:4722 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 alloc_pages_noprof mm/mempolicy.c:2345 [inline] folio_alloc_noprof+0x128/0x180 mm/mempolicy.c:2352 filemap_alloc_folio_noprof+0xdf/0x500 mm/filemap.c:1010 do_read_cache_folio+0x2eb/0x850 mm/filemap.c:3787 read_mapping_folio include/linux/pagemap.h:1011 [inline] f2fs_commit_super+0x3c0/0x7d0 fs/f2fs/super.c:4032 f2fs_record_stop_reason+0x13b/0x1d0 fs/f2fs/super.c:4079 f2fs_handle_critical_error+0x2ac/0x5c0 fs/f2fs/super.c:4174 f2fs_write_inode+0x35f/0x4d0 fs/f2fs/inode.c:785 write_inode fs/fs-writeback.c:1503 [inline] __writeback_single_inode+0x711/0x10d0 fs/fs-writeback.c:1723 writeback_single_inode+0x1f3/0x660 fs/fs-writeback.c:1779 sync_inode_metadata+0xc4/0x120 fs/fs-writeback.c:2849 f2fs_release_file+0xa8/0x100 fs/f2fs/file.c:1941 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:228 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop kernel/entry/common.c:114 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x168/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-56744"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-29T12:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()\n\nsyzbot reports deadlock issue of f2fs as below:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.12.0-rc3-syzkaller-00087-gc964ced77262 #0 Not tainted\n------------------------------------------------------\nkswapd0/79 is trying to acquire lock:\nffff888011824088 (\u0026sbi-\u003esb_lock){++++}-{3:3}, at: f2fs_down_write fs/f2fs/f2fs.h:2199 [inline]\nffff888011824088 (\u0026sbi-\u003esb_lock){++++}-{3:3}, at: f2fs_record_stop_reason+0x52/0x1d0 fs/f2fs/super.c:4068\n\nbut task is already holding lock:\nffff88804bd92610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #2 (sb_internal#2){.+.+}-{0:0}:\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n percpu_down_read include/linux/percpu-rwsem.h:51 [inline]\n __sb_start_write include/linux/fs.h:1716 [inline]\n sb_start_intwrite+0x4d/0x1c0 include/linux/fs.h:1899\n f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842\n evict+0x4e8/0x9b0 fs/inode.c:725\n f2fs_evict_inode+0x1a4/0x15c0 fs/f2fs/inode.c:807\n evict+0x4e8/0x9b0 fs/inode.c:725\n dispose_list fs/inode.c:774 [inline]\n prune_icache_sb+0x239/0x2f0 fs/inode.c:963\n super_cache_scan+0x38c/0x4b0 fs/super.c:223\n do_shrink_slab+0x701/0x1160 mm/shrinker.c:435\n shrink_slab+0x1093/0x14d0 mm/shrinker.c:662\n shrink_one+0x43b/0x850 mm/vmscan.c:4818\n shrink_many mm/vmscan.c:4879 [inline]\n lru_gen_shrink_node mm/vmscan.c:4957 [inline]\n shrink_node+0x3799/0x3de0 mm/vmscan.c:5937\n kswapd_shrink_node mm/vmscan.c:6765 [inline]\n balance_pgdat mm/vmscan.c:6957 [inline]\n kswapd+0x1ca3/0x3700 mm/vmscan.c:7226\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\n-\u003e #1 (fs_reclaim){+.+.}-{0:0}:\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __fs_reclaim_acquire mm/page_alloc.c:3834 [inline]\n fs_reclaim_acquire+0x88/0x130 mm/page_alloc.c:3848\n might_alloc include/linux/sched/mm.h:318 [inline]\n prepare_alloc_pages+0x147/0x5b0 mm/page_alloc.c:4493\n __alloc_pages_noprof+0x16f/0x710 mm/page_alloc.c:4722\n alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265\n alloc_pages_noprof mm/mempolicy.c:2345 [inline]\n folio_alloc_noprof+0x128/0x180 mm/mempolicy.c:2352\n filemap_alloc_folio_noprof+0xdf/0x500 mm/filemap.c:1010\n do_read_cache_folio+0x2eb/0x850 mm/filemap.c:3787\n read_mapping_folio include/linux/pagemap.h:1011 [inline]\n f2fs_commit_super+0x3c0/0x7d0 fs/f2fs/super.c:4032\n f2fs_record_stop_reason+0x13b/0x1d0 fs/f2fs/super.c:4079\n f2fs_handle_critical_error+0x2ac/0x5c0 fs/f2fs/super.c:4174\n f2fs_write_inode+0x35f/0x4d0 fs/f2fs/inode.c:785\n write_inode fs/fs-writeback.c:1503 [inline]\n __writeback_single_inode+0x711/0x10d0 fs/fs-writeback.c:1723\n writeback_single_inode+0x1f3/0x660 fs/fs-writeback.c:1779\n sync_inode_metadata+0xc4/0x120 fs/fs-writeback.c:2849\n f2fs_release_file+0xa8/0x100 fs/f2fs/file.c:1941\n __fput+0x23f/0x880 fs/file_table.c:431\n task_work_run+0x24f/0x310 kernel/task_work.c:228\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop kernel/entry/common.c:114 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x168/0x370 kernel/entry/common.c:218\n do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n---truncated---",
"id": "GHSA-x63m-j7x3-7j84",
"modified": "2025-01-08T00:30:48Z",
"published": "2024-12-29T12:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56744"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1539a088b108996bcdaddb7775070b5163b14233"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/801092a2c9c251ef6a8678fcb8fcc1220474a697"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ecf4e6782b01fd578b565b3dd2be7bb0ac91082e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f10a890308a7cd8794e21f646f09827c6cb4bf5d"
}
],
"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-X66G-5578-7PX9
Vulnerability from github – Published: 2024-03-13 15:31 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix RELEASE_LOCKOWNER
The test on so_count in nfsd4_release_lockowner() is nonsense and harmful. Revert to using check_for_locks(), changing that to not sleep.
First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour.
If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error.
The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible. It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request.
When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero. However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID.
So clearly it is harmful to allow a false positive, which testing so_count allows.
The test is nonsense because ... well... it doesn't mean anything.
so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks.
When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked(). It is not clear what the other one is expected to be.
In practice, the count is often 2 because there is precisely one state on so_stateids. If there were more, this would fail.
In my testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before RELEASE_LOCKOWNER. That results in all the lock states being removed, and so the lockowner being discarded (it is removed when there are no more references which usually happens when the lock state is discarded). When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success.
The other case shows an so_count of '2' and precisely one state listed in so_stateid. It appears that the Linux client uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2' is safe. For another client it might not be safe.
So this patch changes check_for_locks() to use the (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls nfsd_file_put(), and so never sleeps. With this check is it safe to restore the use of check_for_locks() rather than testing so_count against the mysterious '2'.
{
"affected": [],
"aliases": [
"CVE-2024-26629"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-13T14:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix RELEASE_LOCKOWNER\n\nThe test on so_count in nfsd4_release_lockowner() is nonsense and\nharmful. Revert to using check_for_locks(), changing that to not sleep.\n\nFirst: harmful.\nAs is documented in the kdoc comment for nfsd4_release_lockowner(), the\ntest on so_count can transiently return a false positive resulting in a\nreturn of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is\nclearly a protocol violation and with the Linux NFS client it can cause\nincorrect behaviour.\n\nIf RELEASE_LOCKOWNER is sent while some other thread is still\nprocessing a LOCK request which failed because, at the time that request\nwas received, the given owner held a conflicting lock, then the nfsd\nthread processing that LOCK request can hold a reference (conflock) to\nthe lock owner that causes nfsd4_release_lockowner() to return an\nincorrect error.\n\nThe Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it\nnever sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so\nit knows that the error is impossible. It assumes the lock owner was in\nfact released so it feels free to use the same lock owner identifier in\nsome later locking request.\n\nWhen it does reuse a lock owner identifier for which a previous RELEASE\nfailed, it will naturally use a lock_seqid of zero. However the server,\nwhich didn\u0027t release the lock owner, will expect a larger lock_seqid and\nso will respond with NFS4ERR_BAD_SEQID.\n\nSo clearly it is harmful to allow a false positive, which testing\nso_count allows.\n\nThe test is nonsense because ... well... it doesn\u0027t mean anything.\n\nso_count is the sum of three different counts.\n1/ the set of states listed on so_stateids\n2/ the set of active vfs locks owned by any of those states\n3/ various transient counts such as for conflicting locks.\n\nWhen it is tested against \u00272\u0027 it is clear that one of these is the\ntransient reference obtained by find_lockowner_str_locked(). It is not\nclear what the other one is expected to be.\n\nIn practice, the count is often 2 because there is precisely one state\non so_stateids. If there were more, this would fail.\n\nIn my testing I see two circumstances when RELEASE_LOCKOWNER is called.\nIn one case, CLOSE is called before RELEASE_LOCKOWNER. That results in\nall the lock states being removed, and so the lockowner being discarded\n(it is removed when there are no more references which usually happens\nwhen the lock state is discarded). When nfsd4_release_lockowner() finds\nthat the lock owner doesn\u0027t exist, it returns success.\n\nThe other case shows an so_count of \u00272\u0027 and precisely one state listed\nin so_stateid. It appears that the Linux client uses a separate lock\nowner for each file resulting in one lock state per lock owner, so this\ntest on \u00272\u0027 is safe. For another client it might not be safe.\n\nSo this patch changes check_for_locks() to use the (newish)\nfind_any_file_locked() so that it doesn\u0027t take a reference on the\nnfs4_file and so never calls nfsd_file_put(), and so never sleeps. With\nthis check is it safe to restore the use of check_for_locks() rather\nthan testing so_count against the mysterious \u00272\u0027.",
"id": "GHSA-x66g-5578-7px9",
"modified": "2026-05-12T12:31:35Z",
"published": "2024-03-13T15:31:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26629"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10d75984495f7fe62152c3b0dbfa3f0a6b739c9b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8f5b860de87039b007e84a28a5eefc888154e098"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/99fb654d01dc3f08b5905c663ad6c89a9d83302f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7d2eee1f53899b53f069bba3a59a419fc3d331b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c6f8b3fcc62725e4129f2c0fd550d022d4a7685a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e4cf8941664cae2f89f0189c29fe2ce8c6be0d03"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/edcf9725150e42beeca42d085149f4c88fa97afd"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/29/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/30/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/30/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-X72C-34X9-QRM4
Vulnerability from github – Published: 2022-05-24 17:17 – Updated: 2022-05-24 17:17An issue was discovered in the Linux kernel through 5.6.11. btree_gc_coalesce in drivers/md/bcache/btree.c has a deadlock if a coalescing operation fails.
{
"affected": [],
"aliases": [
"CVE-2020-12771"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-05-09T21:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in the Linux kernel through 5.6.11. btree_gc_coalesce in drivers/md/bcache/btree.c has a deadlock if a coalescing operation fails.",
"id": "GHSA-x72c-34x9-qrm4",
"modified": "2022-05-24T17:17:34Z",
"published": "2022-05-24T17:17:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12771"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/08/msg00019.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/10/msg00032.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/10/msg00034.html"
},
{
"type": "WEB",
"url": "https://lkml.org/lkml/2020/4/26/87"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20200608-0001"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4462-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4463-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4465-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4483-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4485-1"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-07/msg00071.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-08/msg00009.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-X72X-2X5Q-H4HW
Vulnerability from github – Published: 2025-01-19 12:31 – Updated: 2025-09-26 21:30In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Add a lock when accessing the buddy trim function
When running YouTube videos and Steam games simultaneously, the tester found a system hang / race condition issue with the multi-display configuration setting. Adding a lock to the buddy allocator's trim function would be the solution.
[ 7197.250436] general protection fault, probably for non-canonical address 0xdead000000000108 [ 7197.250447] RIP: 0010:__alloc_range+0x8b/0x340 [amddrm_buddy] [ 7197.250470] Call Trace: [ 7197.250472] [ 7197.250475] ? show_regs+0x6d/0x80 [ 7197.250481] ? die_addr+0x37/0xa0 [ 7197.250483] ? exc_general_protection+0x1db/0x480 [ 7197.250488] ? drm_suballoc_new+0x13c/0x93d [drm_suballoc_helper] [ 7197.250493] ? asm_exc_general_protection+0x27/0x30 [ 7197.250498] ? __alloc_range+0x8b/0x340 [amddrm_buddy] [ 7197.250501] ? __alloc_range+0x109/0x340 [amddrm_buddy] [ 7197.250506] amddrm_buddy_block_trim+0x1b5/0x260 [amddrm_buddy] [ 7197.250511] amdgpu_vram_mgr_new+0x4f5/0x590 [amdgpu] [ 7197.250682] amdttm_resource_alloc+0x46/0xb0 [amdttm] [ 7197.250689] ttm_bo_alloc_resource+0xe4/0x370 [amdttm] [ 7197.250696] amdttm_bo_validate+0x9d/0x180 [amdttm] [ 7197.250701] amdgpu_bo_pin+0x15a/0x2f0 [amdgpu] [ 7197.250831] amdgpu_dm_plane_helper_prepare_fb+0xb2/0x360 [amdgpu] [ 7197.251025] ? try_wait_for_completion+0x59/0x70 [ 7197.251030] drm_atomic_helper_prepare_planes.part.0+0x2f/0x1e0 [ 7197.251035] drm_atomic_helper_prepare_planes+0x5d/0x70 [ 7197.251037] drm_atomic_helper_commit+0x84/0x160 [ 7197.251040] drm_atomic_nonblocking_commit+0x59/0x70 [ 7197.251043] drm_mode_atomic_ioctl+0x720/0x850 [ 7197.251047] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [ 7197.251049] drm_ioctl_kernel+0xb9/0x120 [ 7197.251053] ? srso_alias_return_thunk+0x5/0xfbef5 [ 7197.251056] drm_ioctl+0x2d4/0x550 [ 7197.251058] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [ 7197.251063] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu] [ 7197.251186] __x64_sys_ioctl+0xa0/0xf0 [ 7197.251190] x64_sys_call+0x143b/0x25c0 [ 7197.251193] do_syscall_64+0x7f/0x180 [ 7197.251197] ? srso_alias_return_thunk+0x5/0xfbef5 [ 7197.251199] ? amdgpu_display_user_framebuffer_create+0x215/0x320 [amdgpu] [ 7197.251329] ? drm_internal_framebuffer_create+0xb7/0x1a0 [ 7197.251332] ? srso_alias_return_thunk+0x5/0xfbef5
(cherry picked from commit 3318ba94e56b9183d0304577c74b33b6b01ce516)
{
"affected": [],
"aliases": [
"CVE-2024-57921"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-19T12:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Add a lock when accessing the buddy trim function\n\nWhen running YouTube videos and Steam games simultaneously,\nthe tester found a system hang / race condition issue with\nthe multi-display configuration setting. Adding a lock to\nthe buddy allocator\u0027s trim function would be the solution.\n\n\u003clog snip\u003e\n[ 7197.250436] general protection fault, probably for non-canonical address 0xdead000000000108\n[ 7197.250447] RIP: 0010:__alloc_range+0x8b/0x340 [amddrm_buddy]\n[ 7197.250470] Call Trace:\n[ 7197.250472] \u003cTASK\u003e\n[ 7197.250475] ? show_regs+0x6d/0x80\n[ 7197.250481] ? die_addr+0x37/0xa0\n[ 7197.250483] ? exc_general_protection+0x1db/0x480\n[ 7197.250488] ? drm_suballoc_new+0x13c/0x93d [drm_suballoc_helper]\n[ 7197.250493] ? asm_exc_general_protection+0x27/0x30\n[ 7197.250498] ? __alloc_range+0x8b/0x340 [amddrm_buddy]\n[ 7197.250501] ? __alloc_range+0x109/0x340 [amddrm_buddy]\n[ 7197.250506] amddrm_buddy_block_trim+0x1b5/0x260 [amddrm_buddy]\n[ 7197.250511] amdgpu_vram_mgr_new+0x4f5/0x590 [amdgpu]\n[ 7197.250682] amdttm_resource_alloc+0x46/0xb0 [amdttm]\n[ 7197.250689] ttm_bo_alloc_resource+0xe4/0x370 [amdttm]\n[ 7197.250696] amdttm_bo_validate+0x9d/0x180 [amdttm]\n[ 7197.250701] amdgpu_bo_pin+0x15a/0x2f0 [amdgpu]\n[ 7197.250831] amdgpu_dm_plane_helper_prepare_fb+0xb2/0x360 [amdgpu]\n[ 7197.251025] ? try_wait_for_completion+0x59/0x70\n[ 7197.251030] drm_atomic_helper_prepare_planes.part.0+0x2f/0x1e0\n[ 7197.251035] drm_atomic_helper_prepare_planes+0x5d/0x70\n[ 7197.251037] drm_atomic_helper_commit+0x84/0x160\n[ 7197.251040] drm_atomic_nonblocking_commit+0x59/0x70\n[ 7197.251043] drm_mode_atomic_ioctl+0x720/0x850\n[ 7197.251047] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10\n[ 7197.251049] drm_ioctl_kernel+0xb9/0x120\n[ 7197.251053] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 7197.251056] drm_ioctl+0x2d4/0x550\n[ 7197.251058] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10\n[ 7197.251063] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu]\n[ 7197.251186] __x64_sys_ioctl+0xa0/0xf0\n[ 7197.251190] x64_sys_call+0x143b/0x25c0\n[ 7197.251193] do_syscall_64+0x7f/0x180\n[ 7197.251197] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 7197.251199] ? amdgpu_display_user_framebuffer_create+0x215/0x320 [amdgpu]\n[ 7197.251329] ? drm_internal_framebuffer_create+0xb7/0x1a0\n[ 7197.251332] ? srso_alias_return_thunk+0x5/0xfbef5\n\n(cherry picked from commit 3318ba94e56b9183d0304577c74b33b6b01ce516)",
"id": "GHSA-x72x-2x5q-h4hw",
"modified": "2025-09-26T21:30:27Z",
"published": "2025-01-19T12:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57921"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/758e3c3054b65336cf0c5f240221f63b4fb98478"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75c8b703e5bded1e33b08fb09b829e7c2c1ed50a"
}
],
"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.