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.
2909 vulnerabilities reference this CWE, most recent first.
GHSA-PVHV-2W8W-PF3X
Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2024-12-12 03:33Windows Remote Desktop Services Remote Code Execution Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-49106"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-12T02:04:36Z",
"severity": "HIGH"
},
"details": "Windows Remote Desktop Services Remote Code Execution Vulnerability",
"id": "GHSA-pvhv-2w8w-pf3x",
"modified": "2024-12-12T03:33:05Z",
"published": "2024-12-12T03:33:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49106"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49106"
}
],
"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"
}
]
}
GHSA-PVQ8-VG9V-94RW
Vulnerability from github – Published: 2025-06-20 12:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
net_sched: prio: fix a race in prio_tune()
Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time.
The race is as follows:
CPU 0 CPU 1 [1]: lock root
[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |
This can be abused to underflow a parent's qlen.
Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.
{
"affected": [],
"aliases": [
"CVE-2025-38083"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-20T12:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: prio: fix a race in prio_tune()\n\nGerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer\nfires at the wrong time.\n\nThe race is as follows:\n\nCPU 0 CPU 1\n[1]: lock root\n[2]: qdisc_tree_flush_backlog()\n[3]: unlock root\n |\n | [5]: lock root\n | [6]: rehash\n | [7]: qdisc_tree_reduce_backlog()\n |\n[4]: qdisc_put()\n\nThis can be abused to underflow a parent\u0027s qlen.\n\nCalling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()\nshould fix the race, because all packets will be purged from the qdisc\nbefore releasing the lock.",
"id": "GHSA-pvq8-vg9v-94rw",
"modified": "2026-05-12T15:30:53Z",
"published": "2025-06-20T12:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38083"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20f68e6a9e41693cb0e55e5b9ebbcb40983a4b8f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3aaa7c01cf19d9b9bb64b88b65c3a6fd05da2eb4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4483d8b9127591c60c4eb789d6cab953bc4522a9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/46c15c9d0f65c9ba857d63f53264f4b17e8a715f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53d11560e957d53ee87a0653d258038ce12361b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93f9eeb678d4c9c1abf720b3615fa8299a490845"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d35acc1be3480505b5931f17e4ea9b7617fea4d3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e3f6745006dc9423d2b065b90f191cfa11b1b584"
},
{
"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:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PVRM-6WQ8-V932
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-10-28 21:30In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error
This patch addresses a race condition for an ODP MR that can result in a CQE with an error on the UMR QP.
During the __mlx5_ib_dereg_mr() flow, the following sequence of calls occurs:
mlx5_revoke_mr() mlx5r_umr_revoke_mr() mlx5r_umr_post_send_wait()
At this point, the lkey is freed from the hardware's perspective.
However, concurrently, mlx5_ib_invalidate_range() might be triggered by another task attempting to invalidate a range for the same freed lkey.
This task will: - Acquire the umem_odp->umem_mutex lock. - Call mlx5r_umr_update_xlt() on the UMR QP. - Since the lkey has already been freed, this can lead to a CQE error, causing the UMR QP to enter an error state [1].
To resolve this race condition, the umem_odp->umem_mutex lock is now also acquired as part of the mlx5_revoke_mr() scope. Upon successful revoke, we set umem_odp->private which points to that MR to NULL, preventing any further invalidation attempts on its lkey.
[1] From dmesg:
infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2
WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] [..] Call Trace: mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib] mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib] __mmu_notifier_invalidate_range_start+0x1e1/0x240 zap_page_range_single+0xf1/0x1a0 madvise_vma_behavior+0x677/0x6e0 do_madvise+0x1a2/0x4b0 __x64_sys_madvise+0x25/0x30 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e
{
"affected": [],
"aliases": [
"CVE-2025-21732"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T03:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error\n\nThis patch addresses a race condition for an ODP MR that can result in a\nCQE with an error on the UMR QP.\n\nDuring the __mlx5_ib_dereg_mr() flow, the following sequence of calls\noccurs:\n\nmlx5_revoke_mr()\n mlx5r_umr_revoke_mr()\n mlx5r_umr_post_send_wait()\n\nAt this point, the lkey is freed from the hardware\u0027s perspective.\n\nHowever, concurrently, mlx5_ib_invalidate_range() might be triggered by\nanother task attempting to invalidate a range for the same freed lkey.\n\nThis task will:\n - Acquire the umem_odp-\u003eumem_mutex lock.\n - Call mlx5r_umr_update_xlt() on the UMR QP.\n - Since the lkey has already been freed, this can lead to a CQE error,\n causing the UMR QP to enter an error state [1].\n\nTo resolve this race condition, the umem_odp-\u003eumem_mutex lock is now also\nacquired as part of the mlx5_revoke_mr() scope. Upon successful revoke,\nwe set umem_odp-\u003eprivate which points to that MR to NULL, preventing any\nfurther invalidation attempts on its lkey.\n\n[1] From dmesg:\n\n infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error\n cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2\n\n WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]\n Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core\n CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]\n [..]\n Call Trace:\n \u003cTASK\u003e\n mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib]\n mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib]\n __mmu_notifier_invalidate_range_start+0x1e1/0x240\n zap_page_range_single+0xf1/0x1a0\n madvise_vma_behavior+0x677/0x6e0\n do_madvise+0x1a2/0x4b0\n __x64_sys_madvise+0x25/0x30\n do_syscall_64+0x6b/0x140\n entry_SYSCALL_64_after_hwframe+0x76/0x7e",
"id": "GHSA-pvrm-6wq8-v932",
"modified": "2025-10-28T21:30:26Z",
"published": "2025-02-27T03:34:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21732"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5297f5ddffef47b94172ab0d3d62270002a3dcc1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/abb604a1a9c87255c7a6f3b784410a9707baf467"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b13d32786acabf70a7b04ed24b7468fc3c82977c"
}
],
"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-PVX4-8CJX-478Q
Vulnerability from github – Published: 2022-05-14 02:57 – Updated: 2022-05-14 02:57Race condition in the Charles Proxy Settings suid binary in Charles Proxy before 4.2.1 allows local users to gain privileges via vectors involving the --self-repair option.
{
"affected": [],
"aliases": [
"CVE-2017-15358"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-08-03T18:29:00Z",
"severity": "HIGH"
},
"details": "Race condition in the Charles Proxy Settings suid binary in Charles Proxy before 4.2.1 allows local users to gain privileges via vectors involving the --self-repair option.",
"id": "GHSA-pvx4-8cjx-478q",
"modified": "2022-05-14T02:57:53Z",
"published": "2022-05-14T02:57:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15358"
},
{
"type": "WEB",
"url": "https://m4.rkw.io/blog/cve201715358-local-root-privesc-in-charles-proxy-42.html"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/45107"
}
],
"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-PVXC-V7PP-FMX4
Vulnerability from github – Published: 2023-04-24 21:30 – Updated: 2024-04-04 03:40A race condition was found in the Linux kernel's RxRPC network protocol, within the processing of RxRPC bundles. This issue results from the lack of proper locking when performing operations on an object. This may allow an attacker to escalate privileges and execute arbitrary code in the context of the kernel.
{
"affected": [],
"aliases": [
"CVE-2023-2006"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-24T21:15:09Z",
"severity": "HIGH"
},
"details": "A race condition was found in the Linux kernel\u0027s RxRPC network protocol, within the processing of RxRPC bundles. This issue results from the lack of proper locking when performing operations on an object. This may allow an attacker to escalate privileges and execute arbitrary code in the context of the kernel.",
"id": "GHSA-pvxc-v7pp-fmx4",
"modified": "2024-04-04T03:40:13Z",
"published": "2023-04-24T21:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2006"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/3bcd6c7eaa53"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2189112"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230609-0004"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-23-439"
}
],
"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-PW64-74Q3-2V7R
Vulnerability from github – Published: 2022-05-17 02:55 – Updated: 2022-05-17 02:55Race condition in kernel/ucount.c in the Linux kernel through 4.10.2 allows local users to cause a denial of service (use-after-free and system crash) or possibly have unspecified other impact via crafted system calls that leverage certain decrement behavior that causes incorrect interaction between put_ucounts and get_ucounts.
{
"affected": [],
"aliases": [
"CVE-2017-6874"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-14T09:59:00Z",
"severity": "HIGH"
},
"details": "Race condition in kernel/ucount.c in the Linux kernel through 4.10.2 allows local users to cause a denial of service (use-after-free and system crash) or possibly have unspecified other impact via crafted system calls that leverage certain decrement behavior that causes incorrect interaction between put_ucounts and get_ucounts.",
"id": "GHSA-pw64-74q3-2v7r",
"modified": "2022-05-17T02:55:20Z",
"published": "2022-05-17T02:55:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6874"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/040757f738e13caaa9c5078bca79aa97e11dde88"
},
{
"type": "WEB",
"url": "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=040757f738e13caaa9c5078bca79aa97e11dde88"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96856"
}
],
"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-PW8F-4H65-P7V4
Vulnerability from github – Published: 2026-07-14 18:32 – Updated: 2026-07-14 18:32Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Runtime allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-58527"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T18:18:39Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Runtime allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-pw8f-4h65-p7v4",
"modified": "2026-07-14T18:32:40Z",
"published": "2026-07-14T18:32:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58527"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-58527"
}
],
"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-PW8W-HQ42-R2HW
Vulnerability from github – Published: 2024-09-18 09:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix race between direct IO write and fsync when using same fd
If we have 2 threads that are using the same file descriptor and one of them is doing direct IO writes while the other is doing fsync, we have a race where we can end up either:
1) Attempt a fsync without holding the inode's lock, triggering an assertion failures when assertions are enabled;
2) Do an invalid memory access from the fsync task because the file private points to memory allocated on stack by the direct IO task and it may be used by the fsync task after the stack was destroyed.
The race happens like this:
1) A user space program opens a file descriptor with O_DIRECT;
2) The program spawns 2 threads using libpthread for example;
3) One of the threads uses the file descriptor to do direct IO writes, while the other calls fsync using the same file descriptor.
4) Call task A the thread doing direct IO writes and task B the thread doing fsyncs;
5) Task A does a direct IO write, and at btrfs_direct_write() sets the file's private to an on stack allocated private with the member 'fsync_skip_inode_lock' set to true;
6) Task B enters btrfs_sync_file() and sees that there's a private structure associated to the file which has 'fsync_skip_inode_lock' set to true, so it skips locking the inode's VFS lock;
7) Task A completes the direct IO write, and resets the file's private to NULL since it had no prior private and our private was stack allocated. Then it unlocks the inode's VFS lock;
8) Task B enters btrfs_get_ordered_extents_for_logging(), then the assertion that checks the inode's VFS lock is held fails, since task B never locked it and task A has already unlocked it.
The stack trace produced is the following:
assertion failed: inode_is_locked(&inode->vfs_inode), in fs/btrfs/ordered-data.c:983 ------------[ cut here ]------------ kernel BUG at fs/btrfs/ordered-data.c:983! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 9 PID: 5072 Comm: worker Tainted: G U OE 6.10.5-1-default #1 openSUSE Tumbleweed 69f48d427608e1c09e60ea24c6c55e2ca1b049e8 Hardware name: Acer Predator PH315-52/Covini_CFS, BIOS V1.12 07/28/2020 RIP: 0010:btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs] Code: 50 d6 86 c0 e8 (...) RSP: 0018:ffff9e4a03dcfc78 EFLAGS: 00010246 RAX: 0000000000000054 RBX: ffff9078a9868e98 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff907dce4a7800 RDI: ffff907dce4a7800 RBP: ffff907805518800 R08: 0000000000000000 R09: ffff9e4a03dcfb38 R10: ffff9e4a03dcfb30 R11: 0000000000000003 R12: ffff907684ae7800 R13: 0000000000000001 R14: ffff90774646b600 R15: 0000000000000000 FS: 00007f04b96006c0(0000) GS:ffff907dce480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f32acbfc000 CR3: 00000001fd4fa005 CR4: 00000000003726f0 Call Trace: ? __die_body.cold+0x14/0x24 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x6a/0x90 ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? exc_invalid_op+0x50/0x70 ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? asm_exc_invalid_op+0x1a/0x20 ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] btrfs_sync_file+0x21a/0x4d0 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? __seccomp_filter+0x31d/0x4f0 __x64_sys_fdatasync+0x4f/0x90 do_syscall_64+0x82/0x160 ? do_futex+0xcb/0x190 ? __x64_sys_futex+0x10e/0x1d0 ? switch_fpu_return+0x4f/0xd0 ? syscall_exit_to_user_mode+0x72/0x220 ? do_syscall_64+0x8e/0x160 ? syscall_exit_to_user_mod ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-46734"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-18T08:15:02Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race between direct IO write and fsync when using same fd\n\nIf we have 2 threads that are using the same file descriptor and one of\nthem is doing direct IO writes while the other is doing fsync, we have a\nrace where we can end up either:\n\n1) Attempt a fsync without holding the inode\u0027s lock, triggering an\n assertion failures when assertions are enabled;\n\n2) Do an invalid memory access from the fsync task because the file private\n points to memory allocated on stack by the direct IO task and it may be\n used by the fsync task after the stack was destroyed.\n\nThe race happens like this:\n\n1) A user space program opens a file descriptor with O_DIRECT;\n\n2) The program spawns 2 threads using libpthread for example;\n\n3) One of the threads uses the file descriptor to do direct IO writes,\n while the other calls fsync using the same file descriptor.\n\n4) Call task A the thread doing direct IO writes and task B the thread\n doing fsyncs;\n\n5) Task A does a direct IO write, and at btrfs_direct_write() sets the\n file\u0027s private to an on stack allocated private with the member\n \u0027fsync_skip_inode_lock\u0027 set to true;\n\n6) Task B enters btrfs_sync_file() and sees that there\u0027s a private\n structure associated to the file which has \u0027fsync_skip_inode_lock\u0027 set\n to true, so it skips locking the inode\u0027s VFS lock;\n\n7) Task A completes the direct IO write, and resets the file\u0027s private to\n NULL since it had no prior private and our private was stack allocated.\n Then it unlocks the inode\u0027s VFS lock;\n\n8) Task B enters btrfs_get_ordered_extents_for_logging(), then the\n assertion that checks the inode\u0027s VFS lock is held fails, since task B\n never locked it and task A has already unlocked it.\n\nThe stack trace produced is the following:\n\n assertion failed: inode_is_locked(\u0026inode-\u003evfs_inode), in fs/btrfs/ordered-data.c:983\n ------------[ cut here ]------------\n kernel BUG at fs/btrfs/ordered-data.c:983!\n Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI\n CPU: 9 PID: 5072 Comm: worker Tainted: G U OE 6.10.5-1-default #1 openSUSE Tumbleweed 69f48d427608e1c09e60ea24c6c55e2ca1b049e8\n Hardware name: Acer Predator PH315-52/Covini_CFS, BIOS V1.12 07/28/2020\n RIP: 0010:btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs]\n Code: 50 d6 86 c0 e8 (...)\n RSP: 0018:ffff9e4a03dcfc78 EFLAGS: 00010246\n RAX: 0000000000000054 RBX: ffff9078a9868e98 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: ffff907dce4a7800 RDI: ffff907dce4a7800\n RBP: ffff907805518800 R08: 0000000000000000 R09: ffff9e4a03dcfb38\n R10: ffff9e4a03dcfb30 R11: 0000000000000003 R12: ffff907684ae7800\n R13: 0000000000000001 R14: ffff90774646b600 R15: 0000000000000000\n FS: 00007f04b96006c0(0000) GS:ffff907dce480000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f32acbfc000 CR3: 00000001fd4fa005 CR4: 00000000003726f0\n Call Trace:\n \u003cTASK\u003e\n ? __die_body.cold+0x14/0x24\n ? die+0x2e/0x50\n ? do_trap+0xca/0x110\n ? do_error_trap+0x6a/0x90\n ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n ? exc_invalid_op+0x50/0x70\n ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n ? asm_exc_invalid_op+0x1a/0x20\n ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n btrfs_sync_file+0x21a/0x4d0 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n ? __seccomp_filter+0x31d/0x4f0\n __x64_sys_fdatasync+0x4f/0x90\n do_syscall_64+0x82/0x160\n ? do_futex+0xcb/0x190\n ? __x64_sys_futex+0x10e/0x1d0\n ? switch_fpu_return+0x4f/0xd0\n ? syscall_exit_to_user_mode+0x72/0x220\n ? do_syscall_64+0x8e/0x160\n ? syscall_exit_to_user_mod\n---truncated---",
"id": "GHSA-pw8w-hq42-r2hw",
"modified": "2025-11-04T00:31:28Z",
"published": "2024-09-18T09:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46734"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/01681aa609b5f110502f56c4e3b2938efcf4a5bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7b5595f33c3c273613b590892a578d78186bb400"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd3087582e4fa36e89be4e6f859e75a4400292b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd9253c23aedd61eb5ff11f37a36247cd46faf86"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d116a0b0e02f395cedfb8c725bd67480aa7c428c"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.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-PWC8-MQ5G-V7JF
Vulnerability from github – Published: 2022-05-02 03:54 – Updated: 2022-05-02 03:54Directory Proxy Server (DPS) in Sun Java System Directory Server Enterprise Edition 6.0 through 6.3.1 does not properly handle multiple client connections within a short time window, which allows remote attackers to hijack the backend connection of an authenticated user, and obtain the privileges of this user, by making a client connection in opportunistic circumstances, related to "long binds," aka Bug Ids 6828462 and 6823593.
{
"affected": [],
"aliases": [
"CVE-2009-4440"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-12-28T19:30:00Z",
"severity": "MODERATE"
},
"details": "Directory Proxy Server (DPS) in Sun Java System Directory Server Enterprise Edition 6.0 through 6.3.1 does not properly handle multiple client connections within a short time window, which allows remote attackers to hijack the backend connection of an authenticated user, and obtain the privileges of this user, by making a client connection in opportunistic circumstances, related to \"long binds,\" aka Bug Ids 6828462 and 6823593.",
"id": "GHSA-pwc8-mq5g-v7jf",
"modified": "2022-05-02T03:54:50Z",
"published": "2022-05-02T03:54:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-4440"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/37915"
},
{
"type": "WEB",
"url": "http://sunsolve.sun.com/search/document.do?assetkey=1-21-141958-01-1"
},
{
"type": "WEB",
"url": "http://sunsolve.sun.com/search/document.do?assetkey=1-66-270789-1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/37481"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id?1023389"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/3647"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PWGQ-FV9Q-FF77
Vulnerability from github – Published: 2022-04-30 00:02 – Updated: 2022-04-30 00:02Google Chrome prior to 57.0.2987.98 for Windows and Mac had a race condition, which could cause Chrome to display incorrect certificate information for a site.
{
"affected": [],
"aliases": [
"CVE-2017-5035"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-24T23:59:00Z",
"severity": "HIGH"
},
"details": "Google Chrome prior to 57.0.2987.98 for Windows and Mac had a race condition, which could cause Chrome to display incorrect certificate information for a site.",
"id": "GHSA-pwgq-fv9q-ff77",
"modified": "2022-04-30T00:02:22Z",
"published": "2022-04-30T00:02:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5035"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2017/03/stable-channel-update-for-desktop.html"
},
{
"type": "WEB",
"url": "https://crbug.com/688425"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201704-02"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2017-0499.html"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3810"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96767"
}
],
"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"
}
]
}
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.