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.
2903 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-4FPJ-FH6Q-HX4R
Vulnerability from github – Published: 2022-12-22 21:30 – Updated: 2025-04-16 15:34A race condition could have allowed bypassing the fullscreen notification which could have lead to a fullscreen window spoof being unnoticed.
This bug only affects Firefox for Windows. Other operating systems are unaffected.. This vulnerability affects Firefox ESR < 91.5, Firefox < 96, and Thunderbird < 91.5.
{
"affected": [],
"aliases": [
"CVE-2022-22746"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-22T20:15:00Z",
"severity": "MODERATE"
},
"details": "A race condition could have allowed bypassing the fullscreen notification which could have lead to a fullscreen window spoof being unnoticed.\u003cbr\u003e*This bug only affects Firefox for Windows. Other operating systems are unaffected.*. This vulnerability affects Firefox ESR \u003c 91.5, Firefox \u003c 96, and Thunderbird \u003c 91.5.",
"id": "GHSA-4fpj-fh6q-hx4r",
"modified": "2025-04-16T15:34:05Z",
"published": "2022-12-22T21:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22746"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1735071"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2022-01"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2022-02"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2022-03"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4FV8-W65M-3932
Vulnerability from github – Published: 2022-12-30 16:57 – Updated: 2022-12-30 16:57Impact
A potential race condition issue exists within the Amazon EFS mount helper in efs-utils versions v1.34.3 and below, and aws-efs-csi-driver versions v1.4.7 and below. When using TLS to mount file systems, the mount helper allocates a local port for stunnel to receive NFS connections prior to applying the TLS tunnel. In affected versions, concurrent mount operations can allocate the same local port, leading to either failed mount operations or an inappropriate mapping from an EFS customer’s local mount points to that customer’s EFS file systems.
Affected versions: efs-utils <= v1.34.3, aws-efs-csi-driver <= v1.4.7
Patches
The patches are included in efs-utils version v1.34.4 and newer, and in aws-efs-csi-driver v1.4.8 and newer.
Workarounds
There is no recommended work around. We recommend affected users update the installed version of efs-utils to v1.34.4+ or aws-efs-csi-driver to v1.4.8+ to address this issue.
References
https://github.com/aws/efs-utils/commit/f3a8f88167d55caa2f78aeb72d4dc1987a9ed62d https://github.com/aws/efs-utils/issues/125 https://github.com/kubernetes-sigs/aws-efs-csi-driver/issues/282 https://github.com/kubernetes-sigs/aws-efs-csi-driver/issues/635
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.4.7"
},
"package": {
"ecosystem": "Go",
"name": "github.com/kubernetes-sigs/aws-efs-csi-driver"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-46174"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-30T16:57:49Z",
"nvd_published_at": "2022-12-28T07:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nA potential race condition issue exists within the Amazon EFS mount helper in efs-utils versions v1.34.3 and below, and aws-efs-csi-driver versions v1.4.7 and below. When using TLS to mount file systems, the mount helper allocates a local port for stunnel to receive NFS connections prior to applying the TLS tunnel. In affected versions, concurrent mount operations can allocate the same local port, leading to either failed mount operations or an inappropriate mapping from an EFS customer\u2019s local mount points to that customer\u2019s EFS file systems.\n\nAffected versions: efs-utils \u003c= v1.34.3, aws-efs-csi-driver \u003c= v1.4.7\n\n### Patches\nThe patches are included in efs-utils version v1.34.4 and newer, and in aws-efs-csi-driver v1.4.8 and newer.\n\n### Workarounds\nThere is no recommended work around. We recommend affected users update the installed version of efs-utils to v1.34.4+ or aws-efs-csi-driver to v1.4.8+ to address this issue.\n\n### References\nhttps://github.com/aws/efs-utils/commit/f3a8f88167d55caa2f78aeb72d4dc1987a9ed62d\nhttps://github.com/aws/efs-utils/issues/125\nhttps://github.com/kubernetes-sigs/aws-efs-csi-driver/issues/282\nhttps://github.com/kubernetes-sigs/aws-efs-csi-driver/issues/635\n",
"id": "GHSA-4fv8-w65m-3932",
"modified": "2022-12-30T16:57:49Z",
"published": "2022-12-30T16:57:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aws/efs-utils/security/advisories/GHSA-4fv8-w65m-3932"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46174"
},
{
"type": "WEB",
"url": "https://github.com/aws/efs-utils/issues/125"
},
{
"type": "WEB",
"url": "https://github.com/aws/efs-utils/commit/f3a8f88167d55caa2f78aeb72d4dc1987a9ed62d"
},
{
"type": "PACKAGE",
"url": "https://github.com/aws/efs-utils"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "efs-utils and aws-efs-csi-driver have race condition during concurrent TLS mounts"
}
GHSA-4FXC-HV2C-FX52
Vulnerability from github – Published: 2022-12-06 09:30 – Updated: 2022-12-07 18:30In wlan driver, there is a race condition, This could lead to local denial of service in wlan services.
{
"affected": [],
"aliases": [
"CVE-2022-42770"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-06T07:15:00Z",
"severity": "MODERATE"
},
"details": "In wlan driver, there is a race condition, This could lead to local denial of service in wlan services.",
"id": "GHSA-4fxc-hv2c-fx52",
"modified": "2022-12-07T18:30:28Z",
"published": "2022-12-06T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42770"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1599588060988411006"
}
],
"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-4G4X-F3F9-GPQ4
Vulnerability from github – Published: 2026-04-01 09:31 – Updated: 2026-04-18 09:30In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix race between freeing data and fs accessing it
AppArmor was putting the reference to i_private data on its end after removing the original entry from the file system. However the inode can aand does live beyond that point and it is possible that some of the fs call back functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs.
While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private.
Fix this by moving the put of i_private referenced data to the correct place which is during inode eviction.
{
"affected": [],
"aliases": [
"CVE-2026-23411"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-01T09:16:17Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix race between freeing data and fs accessing it\n\nAppArmor was putting the reference to i_private data on its end after\nremoving the original entry from the file system. However the inode\ncan aand does live beyond that point and it is possible that some of\nthe fs call back functions will be invoked after the reference has\nbeen put, which results in a race between freeing the data and\naccessing it through the fs.\n\nWhile the rawdata/loaddata is the most likely candidate to fail the\nrace, as it has the fewest references. If properly crafted it might be\npossible to trigger a race for the other types stored in i_private.\n\nFix this by moving the put of i_private referenced data to the correct\nplace which is during inode eviction.",
"id": "GHSA-4g4x-f3f9-gpq4",
"modified": "2026-04-18T09:30:19Z",
"published": "2026-04-01T09:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23411"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13bc2772414d68e94e273dea013181a986948ddf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a732ed26fbd048e7925d227af8cf9ea43fb5cc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ddb961d2929bbb3204a2bba21b5d8153cd3f7cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/667df93769c02ff581c77d2d8f162147e719c557"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8e135b8aee5a06c52a4347a5a6d51223c6f36ba3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a92c5e5086a87d082696245a8607666da3d80554"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae10787d955fb255d381e0d5589451dd72c614b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eecce026399917f6efa532c56bc7a3e9dd6ee68b"
}
],
"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"
}
]
}
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.