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-4C77-8JRG-W382
Vulnerability from github – Published: 2025-07-25 18:30 – Updated: 2025-11-19 18:31In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix race between DIM disable and net_dim()
There's a race between disabling DIM and NAPI callbacks using the dim pointer on the RQ or SQ.
If NAPI checks the DIM state bit and sees it still set, it assumes
rq->dim or sq->dim is valid. But if DIM gets disabled right after
that check, the pointer might already be set to NULL, leading to a NULL
pointer dereference in net_dim().
Fix this by calling synchronize_net() before freeing the DIM context.
This ensures all in-progress NAPI callbacks are finished before the
pointer is cleared.
Kernel log:
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:net_dim+0x23/0x190 ... Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? common_interrupt+0xf/0xa0 ? sysvec_call_function_single+0xb/0x90 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? net_dim+0x23/0x190 ? mlx5e_poll_ico_cq+0x41/0x6f0 [mlx5_core] ? sysvec_apic_timer_interrupt+0xb/0x90 mlx5e_handle_rx_dim+0x92/0xd0 [mlx5_core] mlx5e_napi_poll+0x2cd/0xac0 [mlx5_core] ? mlx5e_poll_ico_cq+0xe5/0x6f0 [mlx5_core] busy_poll_stop+0xa2/0x200 ? mlx5e_napi_poll+0x1d9/0xac0 [mlx5_core] ? mlx5e_trigger_irq+0x130/0x130 [mlx5_core] __napi_busy_loop+0x345/0x3b0 ? sysvec_call_function_single+0xb/0x90 ? asm_sysvec_call_function_single+0x16/0x20 ? sysvec_apic_timer_interrupt+0xb/0x90 ? pcpu_free_area+0x1e4/0x2e0 napi_busy_loop+0x11/0x20 xsk_recvmsg+0x10c/0x130 sock_recvmsg+0x44/0x70 __sys_recvfrom+0xbc/0x130 ? __schedule+0x398/0x890 __x64_sys_recvfrom+0x20/0x30 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ... ---[ end trace 0000000000000000 ]--- ... ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
{
"affected": [],
"aliases": [
"CVE-2025-38440"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T16:15:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix race between DIM disable and net_dim()\n\nThere\u0027s a race between disabling DIM and NAPI callbacks using the dim\npointer on the RQ or SQ.\n\nIf NAPI checks the DIM state bit and sees it still set, it assumes\n`rq-\u003edim` or `sq-\u003edim` is valid. But if DIM gets disabled right after\nthat check, the pointer might already be set to NULL, leading to a NULL\npointer dereference in net_dim().\n\nFix this by calling `synchronize_net()` before freeing the DIM context.\nThis ensures all in-progress NAPI callbacks are finished before the\npointer is cleared.\n\nKernel log:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n...\nRIP: 0010:net_dim+0x23/0x190\n...\nCall Trace:\n \u003cTASK\u003e\n ? __die+0x20/0x60\n ? page_fault_oops+0x150/0x3e0\n ? common_interrupt+0xf/0xa0\n ? sysvec_call_function_single+0xb/0x90\n ? exc_page_fault+0x74/0x130\n ? asm_exc_page_fault+0x22/0x30\n ? net_dim+0x23/0x190\n ? mlx5e_poll_ico_cq+0x41/0x6f0 [mlx5_core]\n ? sysvec_apic_timer_interrupt+0xb/0x90\n mlx5e_handle_rx_dim+0x92/0xd0 [mlx5_core]\n mlx5e_napi_poll+0x2cd/0xac0 [mlx5_core]\n ? mlx5e_poll_ico_cq+0xe5/0x6f0 [mlx5_core]\n busy_poll_stop+0xa2/0x200\n ? mlx5e_napi_poll+0x1d9/0xac0 [mlx5_core]\n ? mlx5e_trigger_irq+0x130/0x130 [mlx5_core]\n __napi_busy_loop+0x345/0x3b0\n ? sysvec_call_function_single+0xb/0x90\n ? asm_sysvec_call_function_single+0x16/0x20\n ? sysvec_apic_timer_interrupt+0xb/0x90\n ? pcpu_free_area+0x1e4/0x2e0\n napi_busy_loop+0x11/0x20\n xsk_recvmsg+0x10c/0x130\n sock_recvmsg+0x44/0x70\n __sys_recvfrom+0xbc/0x130\n ? __schedule+0x398/0x890\n __x64_sys_recvfrom+0x20/0x30\n do_syscall_64+0x4c/0x100\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n...\n---[ end trace 0000000000000000 ]---\n...\n---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---",
"id": "GHSA-4c77-8jrg-w382",
"modified": "2025-11-19T18:31:16Z",
"published": "2025-07-25T18:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38440"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2bc6fb90486e42dd80e660ef7a40c02b2516c6d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7581afc051542e11ccf3ade68acd01b7fb1a3cde"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb41a264a3a576dc040ee37c3d9d6b7e2d9be968"
}
],
"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-4C8W-67QJ-C8VP
Vulnerability from github – Published: 2025-05-30 18:31 – Updated: 2025-11-03 21:33Race condition in Canonical apport up to and including 2.32.0 allows a local attacker to leak sensitive information via PID-reuse by leveraging namespaces.
When handling a crash, the function _check_global_pid_and_forward, which detects if the crashing process resided in a container, was being called before consistency_checks, which attempts to detect if the crashing process had been replaced. Because of this, if a process crashed and was quickly replaced with a containerized one, apport could be made to forward the core dump to the container, potentially leaking sensitive information. consistency_checks is now being called before _check_global_pid_and_forward. Additionally, given that the PID-reuse race condition cannot be reliably detected from userspace alone, crashes are only forwarded to containers if the kernel provided a pidfd, or if the crashing process was unprivileged (i.e., if dump mode == 1).
{
"affected": [],
"aliases": [
"CVE-2025-5054"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-30T18:15:32Z",
"severity": "MODERATE"
},
"details": "Race condition in Canonical apport up to and including 2.32.0 allows a local attacker to leak sensitive information via PID-reuse by leveraging namespaces.\n\n\n\n\nWhen handling a crash, the function `_check_global_pid_and_forward`, which detects if the crashing process resided in a container, was being called before `consistency_checks`, which attempts to detect if the crashing process had been replaced. Because of this, if a process crashed and was quickly replaced with a containerized one, apport could be made to forward the core dump to the container, potentially leaking sensitive information. `consistency_checks` is now being called before `_check_global_pid_and_forward`. Additionally, given that the PID-reuse race condition cannot be reliably detected from userspace alone, crashes are only forwarded to containers if the kernel provided a pidfd, or if the crashing process was unprivileged (i.e., if dump mode == 1).",
"id": "GHSA-4c8w-67qj-c8vp",
"modified": "2025-11-03T21:33:59Z",
"published": "2025-05-30T18:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5054"
},
{
"type": "WEB",
"url": "https://ubuntu.com/security/CVE-2025-5054"
},
{
"type": "WEB",
"url": "https://ubuntu.com/security/notices/USN-7545-1"
},
{
"type": "WEB",
"url": "https://www.qualys.com/2025/05/29/apport-coredump/apport-coredump.txt"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Jun/9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4CFC-W93H-9987
Vulnerability from github – Published: 2022-10-12 12:00 – Updated: 2025-01-03 00:31Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-22035, CVE-2022-24504, CVE-2022-33634, CVE-2022-38000, CVE-2022-38047, CVE-2022-41081.
{
"affected": [],
"aliases": [
"CVE-2022-30198"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-11T19:15:00Z",
"severity": "HIGH"
},
"details": "Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-22035, CVE-2022-24504, CVE-2022-33634, CVE-2022-38000, CVE-2022-38047, CVE-2022-41081.",
"id": "GHSA-4cfc-w93h-9987",
"modified": "2025-01-03T00:31:05Z",
"published": "2022-10-12T12:00:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30198"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-30198"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-30198"
}
],
"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-4CMM-H58V-XQP3
Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-05-24 19:13A race condition was addressed with additional validation. This issue is fixed in Security Update 2021-002 Catalina, Security Update 2021-003 Mojave, iOS 14.5 and iPadOS 14.5, watchOS 7.4, tvOS 14.5, macOS Big Sur 11.3. A malicious application may be able to gain root privileges.
{
"affected": [],
"aliases": [
"CVE-2021-30652"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-08T15:15:00Z",
"severity": "HIGH"
},
"details": "A race condition was addressed with additional validation. This issue is fixed in Security Update 2021-002 Catalina, Security Update 2021-003 Mojave, iOS 14.5 and iPadOS 14.5, watchOS 7.4, tvOS 14.5, macOS Big Sur 11.3. A malicious application may be able to gain root privileges.",
"id": "GHSA-4cmm-h58v-xqp3",
"modified": "2022-05-24T19:13:30Z",
"published": "2022-05-24T19:13:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30652"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT212317"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT212323"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT212324"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT212325"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT212326"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT212327"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4F47-65F7-V2G8
Vulnerability from github – Published: 2022-01-15 00:01 – Updated: 2022-01-19 00:01In phTmlNfc_Init and phTmlNfc_CleanUp of phTmlNfc.cc, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-9Android ID: A-197353344
{
"affected": [],
"aliases": [
"CVE-2021-39629"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-14T20:15:00Z",
"severity": "HIGH"
},
"details": "In phTmlNfc_Init and phTmlNfc_CleanUp of phTmlNfc.cc, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-9Android ID: A-197353344",
"id": "GHSA-4f47-65f7-v2g8",
"modified": "2022-01-19T00:01:26Z",
"published": "2022-01-15T00:01:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39629"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2022-01-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4F53-WPQ5-XM54
Vulnerability from github – Published: 2022-11-19 00:30 – Updated: 2022-11-21 03:30Auth. (subscriber+) Race Condition vulnerability in WP-Polls plugin <= 2.76.0 on WordPress.
{
"affected": [],
"aliases": [
"CVE-2022-40130"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-18T23:15:00Z",
"severity": "LOW"
},
"details": "Auth. (subscriber+) Race Condition vulnerability in WP-Polls plugin \u003c= 2.76.0 on WordPress.",
"id": "GHSA-4f53-wpq5-xm54",
"modified": "2022-11-21T03:30:24Z",
"published": "2022-11-19T00:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40130"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/wp-polls/wordpress-wp-polls-plugin-2-76-0-race-condition-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/wp-polls/#developers"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4F5G-H3X2-8V9X
Vulnerability from github – Published: 2023-06-19 00:30 – Updated: 2024-10-21 18:30An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in renesas_usb3_remove in drivers/usb/gadget/udc/renesas_usb3.c.
{
"affected": [],
"aliases": [
"CVE-2023-35828"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-18T22:15:09Z",
"severity": "HIGH"
},
"details": "An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in renesas_usb3_remove in drivers/usb/gadget/udc/renesas_usb3.c.",
"id": "GHSA-4f5g-h3x2-8v9x",
"modified": "2024-10-21T18:30:45Z",
"published": "2023-06-19T00:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35828"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b947f8769be8b8181dc795fd292d3e7120f5204"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/all/20230327121700.52d881e0%40canb.auug.org.au"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/all/20230327121700.52d881e0@canb.auug.org.au"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/lkml/CAJedcCwkuznS1kSTvJXhzPoavcZDWNhNMshi-Ux0spSVRwU=RA%40mail.gmail.com/T"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/lkml/CAJedcCwkuznS1kSTvJXhzPoavcZDWNhNMshi-Ux0spSVRwU=RA@mail.gmail.com/T"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230803-0002"
}
],
"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-4F8R-QQR9-FQ8J
Vulnerability from github – Published: 2024-10-01 18:13 – Updated: 2024-10-11 14:23During the ongoing work on the TUF conformance test suite, we have come across a test that reveals what we believe is a bug in go-tuf with security implications. The bug exists in go-tuf delegation tracing and could result in downloading the wrong artifact.
We have come across this issue in the test in this PR: https://github.com/theupdateframework/tuf-conformance/pull/115.
The test - test_graph_traversal - sets up a repository with a series of delegations, invokes the clients refresh() and then checks the order in which the client traced the delegations. The test shows that the go-tuf client inconsistently traces the delegations in a wrong way. For example, during one CI run, the two-level-delegations test case triggered a wrong order. The delegations in this look as such:
"two-level-delegations": DelegationsTestCase(
delegations=[
DelegationTester("targets", "A"),
DelegationTester("targets", "B"),
DelegationTester("B", "C"),
],
visited_order=["A", "B", "C"],
),
Here, targets delegate to "A", and to "B", and "B" delegates to "C". The client should trace the delegations in the order "A" then "B" then "C" but in this particular CI run, go-tuf traced the delegations "B"->"C"->"A".
In a subsequent CI run, this test case did not fail, but another one did.
@jku has done a bit of debugging and believes that the returned map of GetRolesForTarget returns a map that causes this behavior:
https://github.com/theupdateframework/go-tuf/blob/f95222bdd22d2ac4e5b8ed6fe912b645e213c3b5/metadata/metadata.go#L565-L580
We believe that this map should be an ordered list instead of a map.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/theupdateframework/go-tuf/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-47534"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-01T18:13:25Z",
"nvd_published_at": "2024-10-01T16:15:09Z",
"severity": "HIGH"
},
"details": "During the ongoing work on the TUF conformance test suite, we have come across a test that reveals what we believe is a bug in go-tuf with security implications. The bug exists in go-tuf delegation tracing and could result in downloading the wrong artifact. \n\nWe have come across this issue in the test in this PR: https://github.com/theupdateframework/tuf-conformance/pull/115.\n\nThe test - `test_graph_traversal` - sets up a repository with a series of delegations, invokes the clients `refresh()` and then checks the order in which the client traced the delegations. The test shows that the go-tuf client inconsistently traces the delegations in a wrong way. For example, [during one CI run](https://github.com/theupdateframework/tuf-conformance/pull/115#issuecomment-2275625542), the `two-level-delegations` test case triggered a wrong order. The delegations in this look as such:\n\n```python\n\"two-level-delegations\": DelegationsTestCase(\n delegations=[\n DelegationTester(\"targets\", \"A\"),\n DelegationTester(\"targets\", \"B\"),\n DelegationTester(\"B\", \"C\"),\n ],\n visited_order=[\"A\", \"B\", \"C\"],\n ),\n```\n\nHere, `targets` delegate to `\"A\"`, and to `\"B\"`, and `\"B\"` delegates to `\"C\"`. The client should trace the delegations in the order `\"A\"` then `\"B\"` then `\"C\"` but in this particular CI run, go-tuf traced the delegations `\"B\"-\u003e\"C\"-\u003e\"A\"`.\n\nIn a subsequent CI run, this test case did not fail, but [another one did](https://github.com/theupdateframework/tuf-conformance/pull/115#issuecomment-2275640487).\n\n@jku has done a bit of debugging and believes that the returned map of `GetRolesForTarget` returns a map that causes this behavior:\n\nhttps://github.com/theupdateframework/go-tuf/blob/f95222bdd22d2ac4e5b8ed6fe912b645e213c3b5/metadata/metadata.go#L565-L580\n\nWe believe that this map should be an ordered list instead of a map.",
"id": "GHSA-4f8r-qqr9-fq8j",
"modified": "2024-10-11T14:23:04Z",
"published": "2024-10-01T18:13:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/theupdateframework/go-tuf/security/advisories/GHSA-4f8r-qqr9-fq8j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47534"
},
{
"type": "WEB",
"url": "https://github.com/theupdateframework/tuf-conformance/pull/115"
},
{
"type": "WEB",
"url": "https://github.com/theupdateframework/go-tuf/commit/edc30b474f5afd4cc603e17149704d5aa605151d"
},
{
"type": "WEB",
"url": "https://github.com/theupdateframework/go-tuf/commit/f36420caba9edbfdfd64f95a9554c0836d9cf819"
},
{
"type": "PACKAGE",
"url": "https://github.com/theupdateframework/go-tuf"
},
{
"type": "WEB",
"url": "https://github.com/theupdateframework/go-tuf/blob/f95222bdd22d2ac4e5b8ed6fe912b645e213c3b5/metadata/metadata.go#L565-L580"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2024-3166"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Incorrect delegation lookups can make go-tuf download the wrong artifact"
}
GHSA-4FFP-3CF5-9HGM
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 Operating Systems allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-50317"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T18:17:30Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Operating Systems allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-4ffp-3cf5-9hgm",
"modified": "2026-07-14T18:32:15Z",
"published": "2026-07-14T18:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50317"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50317"
}
],
"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-4FPG-2M6R-6CC4
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-09-24 21:30In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: oa_tc6: fix tx skb race condition between reference pointers
There are two skb pointers to manage tx skb's enqueued from n/w stack. waiting_tx_skb pointer points to the tx skb which needs to be processed and ongoing_tx_skb pointer points to the tx skb which is being processed.
SPI thread prepares the tx data chunks from the tx skb pointed by the ongoing_tx_skb pointer. When the tx skb pointed by the ongoing_tx_skb is processed, the tx skb pointed by the waiting_tx_skb is assigned to ongoing_tx_skb and the waiting_tx_skb pointer is assigned with NULL. Whenever there is a new tx skb from n/w stack, it will be assigned to waiting_tx_skb pointer if it is NULL. Enqueuing and processing of a tx skb handled in two different threads.
Consider a scenario where the SPI thread processed an ongoing_tx_skb and it moves next tx skb from waiting_tx_skb pointer to ongoing_tx_skb pointer without doing any NULL check. At this time, if the waiting_tx_skb pointer is NULL then ongoing_tx_skb pointer is also assigned with NULL. After that, if a new tx skb is assigned to waiting_tx_skb pointer by the n/w stack and there is a chance to overwrite the tx skb pointer with NULL in the SPI thread. Finally one of the tx skb will be left as unhandled, resulting packet missing and memory leak.
- Consider the below scenario where the TXC reported from the previous transfer is 10 and ongoing_tx_skb holds an tx ethernet frame which can be transported in 20 TXCs and waiting_tx_skb is still NULL. tx_credits = 10; / 21 are filled in the previous transfer / ongoing_tx_skb = 20; waiting_tx_skb = NULL; / Still NULL /
- So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true.
- After oa_tc6_prepare_spi_tx_buf_for_tx_skbs() ongoing_tx_skb = 10; waiting_tx_skb = NULL; / Still NULL /
- Perform SPI transfer.
- Process SPI rx buffer to get the TXC from footers.
- Now let's assume previously filled 21 TXCs are freed so we are good to transport the next remaining 10 tx chunks from ongoing_tx_skb. tx_credits = 21; ongoing_tx_skb = 10; waiting_tx_skb = NULL;
- So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true again.
-
In the oa_tc6_prepare_spi_tx_buf_for_tx_skbs() ongoing_tx_skb = NULL; waiting_tx_skb = NULL;
-
Now the below bad case might happen,
Thread1 (oa_tc6_start_xmit) Thread2 (oa_tc6_spi_thread_handler)
- if waiting_tx_skb is NULL - if ongoing_tx_skb is NULL - ongoing_tx_skb = waiting_tx_skb
- waiting_tx_skb = skb - waiting_tx_skb = NULL ... - ongoing_tx_skb = NULL
- if waiting_tx_skb is NULL
- waiting_tx_skb = skb
To overcome the above issue, protect the moving of tx skb reference from waiting_tx_skb pointer to ongoing_tx_skb pointer and assigning new tx skb to waiting_tx_skb pointer, so that the other thread can't access the waiting_tx_skb pointer until the current thread completes moving the tx skb reference safely.
{
"affected": [],
"aliases": [
"CVE-2024-56788"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: oa_tc6: fix tx skb race condition between reference pointers\n\nThere are two skb pointers to manage tx skb\u0027s enqueued from n/w stack.\nwaiting_tx_skb pointer points to the tx skb which needs to be processed\nand ongoing_tx_skb pointer points to the tx skb which is being processed.\n\nSPI thread prepares the tx data chunks from the tx skb pointed by the\nongoing_tx_skb pointer. When the tx skb pointed by the ongoing_tx_skb is\nprocessed, the tx skb pointed by the waiting_tx_skb is assigned to\nongoing_tx_skb and the waiting_tx_skb pointer is assigned with NULL.\nWhenever there is a new tx skb from n/w stack, it will be assigned to\nwaiting_tx_skb pointer if it is NULL. Enqueuing and processing of a tx skb\nhandled in two different threads.\n\nConsider a scenario where the SPI thread processed an ongoing_tx_skb and\nit moves next tx skb from waiting_tx_skb pointer to ongoing_tx_skb pointer\nwithout doing any NULL check. At this time, if the waiting_tx_skb pointer\nis NULL then ongoing_tx_skb pointer is also assigned with NULL. After\nthat, if a new tx skb is assigned to waiting_tx_skb pointer by the n/w\nstack and there is a chance to overwrite the tx skb pointer with NULL in\nthe SPI thread. Finally one of the tx skb will be left as unhandled,\nresulting packet missing and memory leak.\n\n- Consider the below scenario where the TXC reported from the previous\ntransfer is 10 and ongoing_tx_skb holds an tx ethernet frame which can be\ntransported in 20 TXCs and waiting_tx_skb is still NULL.\n\ttx_credits = 10; /* 21 are filled in the previous transfer */\n\tongoing_tx_skb = 20;\n\twaiting_tx_skb = NULL; /* Still NULL */\n- So, (tc6-\u003eongoing_tx_skb || tc6-\u003ewaiting_tx_skb) becomes true.\n- After oa_tc6_prepare_spi_tx_buf_for_tx_skbs()\n\tongoing_tx_skb = 10;\n\twaiting_tx_skb = NULL; /* Still NULL */\n- Perform SPI transfer.\n- Process SPI rx buffer to get the TXC from footers.\n- Now let\u0027s assume previously filled 21 TXCs are freed so we are good to\ntransport the next remaining 10 tx chunks from ongoing_tx_skb.\n\ttx_credits = 21;\n\tongoing_tx_skb = 10;\n\twaiting_tx_skb = NULL;\n- So, (tc6-\u003eongoing_tx_skb || tc6-\u003ewaiting_tx_skb) becomes true again.\n- In the oa_tc6_prepare_spi_tx_buf_for_tx_skbs()\n\tongoing_tx_skb = NULL;\n\twaiting_tx_skb = NULL;\n\n- Now the below bad case might happen,\n\nThread1 (oa_tc6_start_xmit)\tThread2 (oa_tc6_spi_thread_handler)\n---------------------------\t-----------------------------------\n- if waiting_tx_skb is NULL\n\t\t\t\t- if ongoing_tx_skb is NULL\n\t\t\t\t- ongoing_tx_skb = waiting_tx_skb\n- waiting_tx_skb = skb\n\t\t\t\t- waiting_tx_skb = NULL\n\t\t\t\t...\n\t\t\t\t- ongoing_tx_skb = NULL\n- if waiting_tx_skb is NULL\n- waiting_tx_skb = skb\n\nTo overcome the above issue, protect the moving of tx skb reference from\nwaiting_tx_skb pointer to ongoing_tx_skb pointer and assigning new tx skb\nto waiting_tx_skb pointer, so that the other thread can\u0027t access the\nwaiting_tx_skb pointer until the current thread completes moving the tx\nskb reference safely.",
"id": "GHSA-4fpg-2m6r-6cc4",
"modified": "2025-09-24T21:30:31Z",
"published": "2025-01-11T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56788"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f2eb6c32bae04b375bb7a0aedbeefb6dbbcb775"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e592b5110b3e9393881b0a019d86832bbf71a47f"
}
],
"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"
}
]
}
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.