CWE-362
Allowed-with-ReviewConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Abstraction: Class · Status: Draft
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
3596 vulnerabilities reference this CWE, most recent first.
GHSA-9P2R-69C4-V82V
Vulnerability from github – Published: 2024-10-21 12:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
vfs: fix race between evice_inodes() and find_inode()&iput()
Hi, all
Recently I noticed a bug1 in btrfs, after digged it into and I believe it'a race in vfs.
Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super().
cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set
btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict()
Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput().
To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced.
If there is any misunderstanding, please let me know, thanks.
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.
{
"affected": [],
"aliases": [
"CVE-2024-47679"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T12:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvfs: fix race between evice_inodes() and find_inode()\u0026iput()\n\nHi, all\n\nRecently I noticed a bug[1] in btrfs, after digged it into\nand I believe it\u0027a race in vfs.\n\nLet\u0027s assume there\u0027s a inode (ie ino 261) with i_count 1 is\ncalled by iput(), and there\u0027s a concurrent thread calling\ngeneric_shutdown_super().\n\ncpu0: cpu1:\niput() // i_count is 1\n -\u003espin_lock(inode)\n -\u003edec i_count to 0\n -\u003eiput_final() generic_shutdown_super()\n -\u003e__inode_add_lru() -\u003eevict_inodes()\n // cause some reason[2] -\u003eif (atomic_read(inode-\u003ei_count)) continue;\n // return before // inode 261 passed the above check\n // list_lru_add_obj() // and then schedule out\n -\u003espin_unlock()\n// note here: the inode 261\n// was still at sb list and hash list,\n// and I_FREEING|I_WILL_FREE was not been set\n\nbtrfs_iget()\n // after some function calls\n -\u003efind_inode()\n // found the above inode 261\n -\u003espin_lock(inode)\n // check I_FREEING|I_WILL_FREE\n // and passed\n -\u003e__iget()\n -\u003espin_unlock(inode) // schedule back\n -\u003espin_lock(inode)\n // check (I_NEW|I_FREEING|I_WILL_FREE) flags,\n // passed and set I_FREEING\niput() -\u003espin_unlock(inode)\n -\u003espin_lock(inode)\t\t\t -\u003eevict()\n // dec i_count to 0\n -\u003eiput_final()\n -\u003espin_unlock()\n -\u003eevict()\n\nNow, we have two threads simultaneously evicting\nthe same inode, which may trigger the BUG(inode-\u003ei_state \u0026 I_CLEAR)\nstatement both within clear_inode() and iput().\n\nTo fix the bug, recheck the inode-\u003ei_count after holding i_lock.\nBecause in the most scenarios, the first check is valid, and\nthe overhead of spin_lock() can be reduced.\n\nIf there is any misunderstanding, please let me know, thanks.\n\n[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/\n[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()\nreturn false when I reproduced the bug.",
"id": "GHSA-9p2r-69c4-v82v",
"modified": "2025-11-04T00:31:36Z",
"published": "2024-10-21T12:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47679"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/489faddb1ae75b0e1a741fe5ca2542a2b5e794a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c857fb12b9137fee574443385d53914356bbe11"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6cc13a80a26e6b48f78c725c01b91987d61563ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/88b1afbf0f6b221f6c5bb66cc80cd3b38d696687"
},
{
"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:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9P7F-FP2W-2P9P
Vulnerability from github – Published: 2022-11-10 12:01 – Updated: 2022-11-10 12:01Windows Advanced Local Procedure Call (ALPC) Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-41093, CVE-2022-41100.
{
"affected": [],
"aliases": [
"CVE-2022-41045"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-09T22:15:00Z",
"severity": "HIGH"
},
"details": "Windows Advanced Local Procedure Call (ALPC) Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-41093, CVE-2022-41100.",
"id": "GHSA-9p7f-fp2w-2p9p",
"modified": "2022-11-10T12:01:08Z",
"published": "2022-11-10T12:01:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41045"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-41045"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-41045"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9P8R-V33G-4939
Vulnerability from github – Published: 2022-04-30 00:00 – Updated: 2025-03-21 18:31A flaw was found in the QXL display device emulation in QEMU. A double fetch of guest controlled values cursor->header.width and cursor->header.height can lead to the allocation of a small cursor object followed by a subsequent heap-based buffer overflow. A malicious privileged guest user could use this flaw to crash the QEMU process on the host or potentially execute arbitrary code within the context of the QEMU process.
{
"affected": [],
"aliases": [
"CVE-2021-4207"
],
"database_specific": {
"cwe_ids": [
"CWE-120",
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-29T17:15:00Z",
"severity": "HIGH"
},
"details": "A flaw was found in the QXL display device emulation in QEMU. A double fetch of guest controlled values `cursor-\u003eheader.width` and `cursor-\u003eheader.height` can lead to the allocation of a small cursor object followed by a subsequent heap-based buffer overflow. A malicious privileged guest user could use this flaw to crash the QEMU process on the host or potentially execute arbitrary code within the context of the QEMU process.",
"id": "GHSA-9p8r-v33g-4939",
"modified": "2025-03-21T18:31:18Z",
"published": "2022-04-30T00:00:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4207"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2036966"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/09/msg00008.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202208-27"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250321-0009"
},
{
"type": "WEB",
"url": "https://starlabs.sg/advisories/21-4207"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5133"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9P96-44Q4-P2J5
Vulnerability from github – Published: 2026-07-19 12:30 – Updated: 2026-10-15 03:36In the Linux kernel, the following vulnerability has been resolved:
i2c: core: fix adapter registration race
Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device.
Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free.
Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.
{
"affected": [],
"aliases": [
"CVE-2026-53400"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T12:16:51Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: core: fix adapter registration race\n\nAdapters can be looked up based on their id using i2c_get_adapter()\nwhich takes a reference to the embedded struct device.\n\nMake sure that the adapter (including its struct device) has been\ninitialised before adding it to the IDR to avoid accessing uninitialised\ndata which could, for example, lead to NULL-pointer dereferences or\nuse-after-free.\n\nNote that the i2c-dev chardev, which is registered from a bus notifier,\ncurrently uses i2c_get_adapter() so the adapter needs to be added to the\nIDR before registration.",
"id": "GHSA-9p96-44q4-p2j5",
"modified": "2026-10-15T03:36:21Z",
"published": "2026-07-19T12:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53400"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1febb174815bcae56d73587e99e8f87e02f0784d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2e57c788e71f1763445f812eba4e0b4a2fbd0646"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a946038f2a5a8c29048c6af369d4e391448a5c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78793c75dc6d0ff2e4d50ad617349b328a99054e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4365bc41baaf67f3a5aa8556d23544e6ec7480a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4c8094bbf4c6fa68b17e3b16f6a0a1b7a14f3e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ba14d7cf2fe7284610a29854bdff22b2537d3ce6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/da9d8d9711f78deebc202d0cffcf577e45ee8621"
}
],
"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-9PFW-FQV3-483P
Vulnerability from github – Published: 2024-07-16 15:30 – Updated: 2024-07-17 21:31In the Linux kernel, the following vulnerability has been resolved:
ice: Fix race condition during interface enslave
Commit 5dbbbd01cbba83 ("ice: Avoid RTNL lock when re-creating auxiliary device") changes a process of re-creation of aux device so ice_plug_aux_dev() is called from ice_service_task() context. This unfortunately opens a race window that can result in dead-lock when interface has left LAG and immediately enters LAG again.
Reproducer:
#!/bin/sh
ip link add lag0 type bond mode 1 miimon 100
ip link set lag0
for n in {1..10}; do
echo Cycle: $n
ip link set ens7f0 master lag0
sleep 1
ip link set ens7f0 nomaster
done
This results in: [20976.208697] Workqueue: ice ice_service_task [ice] [20976.213422] Call Trace: [20976.215871] __schedule+0x2d1/0x830 [20976.219364] schedule+0x35/0xa0 [20976.222510] schedule_preempt_disabled+0xa/0x10 [20976.227043] __mutex_lock.isra.7+0x310/0x420 [20976.235071] enum_all_gids_of_dev_cb+0x1c/0x100 [ib_core] [20976.251215] ib_enum_roce_netdev+0xa4/0xe0 [ib_core] [20976.256192] ib_cache_setup_one+0x33/0xa0 [ib_core] [20976.261079] ib_register_device+0x40d/0x580 [ib_core] [20976.266139] irdma_ib_register_device+0x129/0x250 [irdma] [20976.281409] irdma_probe+0x2c1/0x360 [irdma] [20976.285691] auxiliary_bus_probe+0x45/0x70 [20976.289790] really_probe+0x1f2/0x480 [20976.298509] driver_probe_device+0x49/0xc0 [20976.302609] bus_for_each_drv+0x79/0xc0 [20976.306448] __device_attach+0xdc/0x160 [20976.310286] bus_probe_device+0x9d/0xb0 [20976.314128] device_add+0x43c/0x890 [20976.321287] __auxiliary_device_add+0x43/0x60 [20976.325644] ice_plug_aux_dev+0xb2/0x100 [ice] [20976.330109] ice_service_task+0xd0c/0xed0 [ice] [20976.342591] process_one_work+0x1a7/0x360 [20976.350536] worker_thread+0x30/0x390 [20976.358128] kthread+0x10a/0x120 [20976.365547] ret_from_fork+0x1f/0x40 ... [20976.438030] task:ip state:D stack: 0 pid:213658 ppid:213627 flags:0x00004084 [20976.446469] Call Trace: [20976.448921] __schedule+0x2d1/0x830 [20976.452414] schedule+0x35/0xa0 [20976.455559] schedule_preempt_disabled+0xa/0x10 [20976.460090] __mutex_lock.isra.7+0x310/0x420 [20976.464364] device_del+0x36/0x3c0 [20976.467772] ice_unplug_aux_dev+0x1a/0x40 [ice] [20976.472313] ice_lag_event_handler+0x2a2/0x520 [ice] [20976.477288] notifier_call_chain+0x47/0x70 [20976.481386] __netdev_upper_dev_link+0x18b/0x280 [20976.489845] bond_enslave+0xe05/0x1790 [bonding] [20976.494475] do_setlink+0x336/0xf50 [20976.502517] __rtnl_newlink+0x529/0x8b0 [20976.543441] rtnl_newlink+0x43/0x60 [20976.546934] rtnetlink_rcv_msg+0x2b1/0x360 [20976.559238] netlink_rcv_skb+0x4c/0x120 [20976.563079] netlink_unicast+0x196/0x230 [20976.567005] netlink_sendmsg+0x204/0x3d0 [20976.570930] sock_sendmsg+0x4c/0x50 [20976.574423] ____sys_sendmsg+0x1eb/0x250 [20976.586807] ___sys_sendmsg+0x7c/0xc0 [20976.606353] __sys_sendmsg+0x57/0xa0 [20976.609930] do_syscall_64+0x5b/0x1a0 [20976.613598] entry_SYSCALL_64_after_hwframe+0x65/0xca
- Command 'ip link ... set nomaster' causes that ice_plug_aux_dev() is called from ice_service_task() context, aux device is created and associated device->lock is taken.
- Command 'ip link ... set master...' calls ice's notifier under RTNL lock and that notifier calls ice_unplug_aux_dev(). That function tries to take aux device->lock but this is already taken by ice_plug_aux_dev() in step 1
- Later ice_plug_aux_dev() tries to take RTNL lock but this is already taken in step 2
- Dead-lock
The patch fixes this issue by following changes: - Bit ICE_FLAG_PLUG_AUX_DEV is kept to be set during ice_plug_aux_dev() call in ice_service_task() - The bit is checked in ice_clear_rdma_cap() and only if it is not set then ice_unplug_aux_dev() is called. If it is set (in other words plugging of aux device was requested and ice_plug_aux_dev() is potentially running) then the function only clears the ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-48842"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T13:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix race condition during interface enslave\n\nCommit 5dbbbd01cbba83 (\"ice: Avoid RTNL lock when re-creating\nauxiliary device\") changes a process of re-creation of aux device\nso ice_plug_aux_dev() is called from ice_service_task() context.\nThis unfortunately opens a race window that can result in dead-lock\nwhen interface has left LAG and immediately enters LAG again.\n\nReproducer:\n```\n#!/bin/sh\n\nip link add lag0 type bond mode 1 miimon 100\nip link set lag0\n\nfor n in {1..10}; do\n echo Cycle: $n\n ip link set ens7f0 master lag0\n sleep 1\n ip link set ens7f0 nomaster\ndone\n```\n\nThis results in:\n[20976.208697] Workqueue: ice ice_service_task [ice]\n[20976.213422] Call Trace:\n[20976.215871] __schedule+0x2d1/0x830\n[20976.219364] schedule+0x35/0xa0\n[20976.222510] schedule_preempt_disabled+0xa/0x10\n[20976.227043] __mutex_lock.isra.7+0x310/0x420\n[20976.235071] enum_all_gids_of_dev_cb+0x1c/0x100 [ib_core]\n[20976.251215] ib_enum_roce_netdev+0xa4/0xe0 [ib_core]\n[20976.256192] ib_cache_setup_one+0x33/0xa0 [ib_core]\n[20976.261079] ib_register_device+0x40d/0x580 [ib_core]\n[20976.266139] irdma_ib_register_device+0x129/0x250 [irdma]\n[20976.281409] irdma_probe+0x2c1/0x360 [irdma]\n[20976.285691] auxiliary_bus_probe+0x45/0x70\n[20976.289790] really_probe+0x1f2/0x480\n[20976.298509] driver_probe_device+0x49/0xc0\n[20976.302609] bus_for_each_drv+0x79/0xc0\n[20976.306448] __device_attach+0xdc/0x160\n[20976.310286] bus_probe_device+0x9d/0xb0\n[20976.314128] device_add+0x43c/0x890\n[20976.321287] __auxiliary_device_add+0x43/0x60\n[20976.325644] ice_plug_aux_dev+0xb2/0x100 [ice]\n[20976.330109] ice_service_task+0xd0c/0xed0 [ice]\n[20976.342591] process_one_work+0x1a7/0x360\n[20976.350536] worker_thread+0x30/0x390\n[20976.358128] kthread+0x10a/0x120\n[20976.365547] ret_from_fork+0x1f/0x40\n...\n[20976.438030] task:ip state:D stack: 0 pid:213658 ppid:213627 flags:0x00004084\n[20976.446469] Call Trace:\n[20976.448921] __schedule+0x2d1/0x830\n[20976.452414] schedule+0x35/0xa0\n[20976.455559] schedule_preempt_disabled+0xa/0x10\n[20976.460090] __mutex_lock.isra.7+0x310/0x420\n[20976.464364] device_del+0x36/0x3c0\n[20976.467772] ice_unplug_aux_dev+0x1a/0x40 [ice]\n[20976.472313] ice_lag_event_handler+0x2a2/0x520 [ice]\n[20976.477288] notifier_call_chain+0x47/0x70\n[20976.481386] __netdev_upper_dev_link+0x18b/0x280\n[20976.489845] bond_enslave+0xe05/0x1790 [bonding]\n[20976.494475] do_setlink+0x336/0xf50\n[20976.502517] __rtnl_newlink+0x529/0x8b0\n[20976.543441] rtnl_newlink+0x43/0x60\n[20976.546934] rtnetlink_rcv_msg+0x2b1/0x360\n[20976.559238] netlink_rcv_skb+0x4c/0x120\n[20976.563079] netlink_unicast+0x196/0x230\n[20976.567005] netlink_sendmsg+0x204/0x3d0\n[20976.570930] sock_sendmsg+0x4c/0x50\n[20976.574423] ____sys_sendmsg+0x1eb/0x250\n[20976.586807] ___sys_sendmsg+0x7c/0xc0\n[20976.606353] __sys_sendmsg+0x57/0xa0\n[20976.609930] do_syscall_64+0x5b/0x1a0\n[20976.613598] entry_SYSCALL_64_after_hwframe+0x65/0xca\n\n1. Command \u0027ip link ... set nomaster\u0027 causes that ice_plug_aux_dev()\n is called from ice_service_task() context, aux device is created\n and associated device-\u003elock is taken.\n2. Command \u0027ip link ... set master...\u0027 calls ice\u0027s notifier under\n RTNL lock and that notifier calls ice_unplug_aux_dev(). That\n function tries to take aux device-\u003elock but this is already taken\n by ice_plug_aux_dev() in step 1\n3. Later ice_plug_aux_dev() tries to take RTNL lock but this is already\n taken in step 2\n4. Dead-lock\n\nThe patch fixes this issue by following changes:\n- Bit ICE_FLAG_PLUG_AUX_DEV is kept to be set during ice_plug_aux_dev()\n call in ice_service_task()\n- The bit is checked in ice_clear_rdma_cap() and only if it is not set\n then ice_unplug_aux_dev() is called. If it is set (in other words\n plugging of aux device was requested and ice_plug_aux_dev() is\n potentially running) then the function only clears the\n---truncated---",
"id": "GHSA-9pfw-fqv3-483p",
"modified": "2024-07-17T21:31:38Z",
"published": "2024-07-16T15:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48842"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5cb1ebdbc4342b1c2ce89516e19808d64417bdbc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a9bbacc53d1f5ed8febbfdf31401d20e005f49ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e1014fc5572375658fa421531cedb6e084f477dc"
}
],
"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-9PHF-M556-W4XG
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:31In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: use uninterruptible resv lock for plane updates
virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held():
WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl
Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list.
Both call sites run inside the .atomic_update plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .prepare_fb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit.
Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of dma_resv_lock_interruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO.
Use it from virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(); check the return value to handle the remaining -ENOMEM case from dma_resv_reserve_fences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable.
Other callers of virtio_gpu_array_lock_resv() (the ioctl paths) continue to use the interruptible variant.
The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences().
{
"affected": [],
"aliases": [
"CVE-2026-64098"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:50Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/virtio: use uninterruptible resv lock for plane updates\n\nvirtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock\nthe framebuffer BO\u0027s dma_resv via virtio_gpu_array_lock_resv() and\nignore its return value. The function can fail with -EINTR from\ndma_resv_lock_interruptible() (signal during lock wait) or with\n-ENOMEM from dma_resv_reserve_fences() (fence slot allocation),\nleaving the resv lock not held. The queue path then walks the object\narray and calls dma_resv_add_fence(), which requires the lock held;\nwith lockdep enabled this trips dma_resv_assert_held():\n\n WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840\n Call Trace:\n virtio_gpu_array_add_fence\n virtio_gpu_queue_ctrl_sgs\n virtio_gpu_queue_fenced_ctrl_buffer\n virtio_gpu_cursor_plane_update\n drm_atomic_helper_commit_planes\n drm_atomic_helper_commit_tail\n commit_tail\n drm_atomic_helper_commit\n drm_atomic_commit\n drm_atomic_helper_update_plane\n __setplane_atomic\n drm_mode_cursor_universal\n drm_mode_cursor_common\n drm_mode_cursor_ioctl\n drm_ioctl\n __x64_sys_ioctl\n\nBeyond the WARN, mutating the dma_resv fence list without the lock\nraces with concurrent readers/writers and can corrupt the list.\n\nBoth call sites run inside the .atomic_update plane callback, which\nDRM atomic helpers do not allow to fail (by the time it runs, the\ncommit has been signed off to userspace and there is no clean\nrollback path). Moving the lock acquisition to .prepare_fb was\nrejected because the broader lock scope deadlocks against other BO\nlocking paths in the same atomic commit.\n\nIntroduce virtio_gpu_lock_one_resv_uninterruptible() that uses\ndma_resv_lock() instead of dma_resv_lock_interruptible(). This\neliminates the -EINTR failure mode -- the realistic syzbot trigger\n-- without extending the lock hold across the commit. The helper\nlocks a single BO and rejects nents \u003e 1 with -EINVAL; both fix\nsites lock exactly one BO.\n\nUse it from virtio_gpu_cursor_plane_update() and\nvirtio_gpu_resource_flush(); check the return value to handle the\nremaining -ENOMEM case from dma_resv_reserve_fences() by freeing\nthe objs and skipping the plane update for that frame. The\nframebuffer BOs touched here are not shared with other contexts\nand lock contention is expected to be brief, so the loss of\nsignal-interruptibility is acceptable.\n\nOther callers of virtio_gpu_array_lock_resv() (the ioctl paths)\ncontinue to use the interruptible variant.\n\nThe bug was reported by syzbot, triggered via fault injection\n(fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the\n-ENOMEM branch in dma_resv_reserve_fences().",
"id": "GHSA-9phf-m556-w4xg",
"modified": "2026-07-20T15:31:59Z",
"published": "2026-07-19T18:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64098"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/21ab64c77a30d56efc506c8fa2ad8959f8ce3d36"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7930eee22cd3df61e85be8aa512032ab303b7167"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8fadd01cf461fee5bb11506621339c548447e5c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9af1b6e175c82daf4b423da339a722d8e67a735a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a2359a411b15f495d12cfda6a7db6855ebb7f90f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c86077d512ee980cc91322211d35dbcd3175f64c"
}
],
"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-9PMW-F3Q3-5RCF
Vulnerability from github – Published: 2022-05-24 17:47 – Updated: 2024-04-04 03:06In the standard library in Rust before 1.19.0, there is a synchronization problem in the MutexGuard object. MutexGuards can be used across threads with any types, allowing for memory safety issues through race conditions.
{
"affected": [],
"aliases": [
"CVE-2017-20004"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-14T07:15:00Z",
"severity": "MODERATE"
},
"details": "In the standard library in Rust before 1.19.0, there is a synchronization problem in the MutexGuard object. MutexGuards can be used across threads with any types, allowing for memory safety issues through race conditions.",
"id": "GHSA-9pmw-f3q3-5rcf",
"modified": "2024-04-04T03:06:06Z",
"published": "2022-05-24T17:47:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-20004"
},
{
"type": "WEB",
"url": "https://github.com/rust-lang/rust/issues/41622"
},
{
"type": "WEB",
"url": "https://github.com/rust-lang/rust/pull/41624"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9PP4-8P8V-G78W
Vulnerability from github – Published: 2021-08-25 20:57 – Updated: 2021-08-18 20:22An issue was discovered in the lever crate before 0.1.1 for Rust. AtomicBox implements the Send and Sync traits for all types T. This allows non-Send types such as Rc and non-Sync types such as Cell to be used across thread boundaries which can trigger undefined behavior and memory corruption.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "lever"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-36457"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-77"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-18T20:22:32Z",
"nvd_published_at": "2021-08-08T06:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in the lever crate before 0.1.1 for Rust. AtomicBox\u003cT\u003e implements the Send and Sync traits for all types T. This allows non-Send types such as Rc and non-Sync types such as Cell to be used across thread boundaries which can trigger undefined behavior and memory corruption.",
"id": "GHSA-9pp4-8p8v-g78w",
"modified": "2021-08-18T20:22:32Z",
"published": "2021-08-25T20:57:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36457"
},
{
"type": "WEB",
"url": "https://github.com/vertexclique/lever/issues/15"
},
{
"type": "WEB",
"url": "https://github.com/vertexclique/lever/pull/17"
},
{
"type": "WEB",
"url": "https://github.com/vertexclique/lever/commit/4a4cca61cdb25061967d58522229e147483007b1"
},
{
"type": "PACKAGE",
"url": "https://github.com/vertexclique/lever"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0137.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Data races in lever"
}
GHSA-9PPX-3J9G-766W
Vulnerability from github – Published: 2023-03-07 00:30 – Updated: 2023-03-11 03:30A flaw was found in samba. A race condition in the password lockout code may lead to the risk of brute force attacks being successful if special conditions are met.
{
"affected": [],
"aliases": [
"CVE-2021-20251"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-06T23:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in samba. A race condition in the password lockout code may lead to the risk of brute force attacks being successful if special conditions are met.",
"id": "GHSA-9ppx-3j9g-766w",
"modified": "2023-03-11T03:30:17Z",
"published": "2023-03-07T00:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20251"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1929800"
},
{
"type": "WEB",
"url": "https://bugzilla.samba.org/show_bug.cgi?id=14611"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202309-06"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230331-0005"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9PQG-GMHR-V6C6
Vulnerability from github – Published: 2025-08-06 06:31 – Updated: 2025-08-06 06:31Race condition vulnerability in the kernel hufs module. Impact: Successful exploitation of this vulnerability may affect service confidentiality.
{
"affected": [],
"aliases": [
"CVE-2025-54651"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-06T04:16:17Z",
"severity": "MODERATE"
},
"details": "Race condition vulnerability in the kernel hufs module.\nImpact: Successful exploitation of this vulnerability may affect service confidentiality.",
"id": "GHSA-9pqg-gmhr-v6c6",
"modified": "2025-08-06T06:31:22Z",
"published": "2025-08-06T06:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54651"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2025/8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
Mitigation
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Mitigation
Use thread-safe capabilities such as the data access abstraction in Spring.
Mitigation
- Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
- Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Mitigation
When using multithreading and operating on shared variables, only use thread-safe functions.
Mitigation
Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
Mitigation
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Mitigation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Mitigation
Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
Mitigation
Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
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-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.