CWE-362
Allowed-with-ReviewConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Abstraction: Class · Status: Draft
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
2900 vulnerabilities reference this CWE, most recent first.
GHSA-6WF7-5HH8-X7VM
Vulnerability from github – Published: 2025-09-16 18:31 – Updated: 2025-12-02 00:31In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: avoid hci_dev_test_and_set_flag() in mgmt_init_hdev()
syzbot is again reporting attempt to cancel uninitialized work at mgmt_index_removed() [1], for setting of HCI_MGMT flag from mgmt_init_hdev() from hci_mgmt_cmd() from hci_sock_sendmsg() can race with testing of HCI_MGMT flag from mgmt_index_removed() from hci_sock_bind() due to lack of serialization via hci_dev_lock().
Since mgmt_init_hdev() is called with mgmt_chan_list_lock held, we can safely split hci_dev_test_and_set_flag() into hci_dev_test_flag() and hci_dev_set_flag(). Thus, in order to close this race, set HCI_MGMT flag after INIT_DELAYED_WORK() completed.
This is a local fix based on mgmt_chan_list_lock. Lack of serialization via hci_dev_lock() might be causing different race conditions somewhere else. But a global fix based on hci_dev_lock() should deserve a future patch.
{
"affected": [],
"aliases": [
"CVE-2022-50339"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T17:15:32Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: avoid hci_dev_test_and_set_flag() in mgmt_init_hdev()\n\nsyzbot is again reporting attempt to cancel uninitialized work\nat mgmt_index_removed() [1], for setting of HCI_MGMT flag from\nmgmt_init_hdev() from hci_mgmt_cmd() from hci_sock_sendmsg() can\nrace with testing of HCI_MGMT flag from mgmt_index_removed() from\nhci_sock_bind() due to lack of serialization via hci_dev_lock().\n\nSince mgmt_init_hdev() is called with mgmt_chan_list_lock held, we can\nsafely split hci_dev_test_and_set_flag() into hci_dev_test_flag() and\nhci_dev_set_flag(). Thus, in order to close this race, set HCI_MGMT flag\nafter INIT_DELAYED_WORK() completed.\n\nThis is a local fix based on mgmt_chan_list_lock. Lack of serialization\nvia hci_dev_lock() might be causing different race conditions somewhere\nelse. But a global fix based on hci_dev_lock() should deserve a future\npatch.",
"id": "GHSA-6wf7-5hh8-x7vm",
"modified": "2025-12-02T00:31:10Z",
"published": "2025-09-16T18:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50339"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e53c6180db8dd09de94e0a3bdf4fef6f5f9dd6e6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f74ca25d6d6629ffd4fd80a1a73037253b57d06b"
}
],
"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-6WQQ-9PPM-4P57
Vulnerability from github – Published: 2022-05-17 01:15 – Updated: 2022-05-17 01:15Unity before 7.2.3 and 7.3.x before 7.3.1, as used in Ubuntu, does not properly take focus of the keyboard when switching to the lock screen, which allows physically proximate attackers to bypass the lock screen by (1) leveraging a machine that had text selected when locking or (2) resuming from a suspension.
{
"affected": [],
"aliases": [
"CVE-2014-5195"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-08-07T11:13:00Z",
"severity": "HIGH"
},
"details": "Unity before 7.2.3 and 7.3.x before 7.3.1, as used in Ubuntu, does not properly take focus of the keyboard when switching to the lock screen, which allows physically proximate attackers to bypass the lock screen by (1) leveraging a machine that had text selected when locking or (2) resuming from a suspension.",
"id": "GHSA-6wqq-9ppm-4p57",
"modified": "2022-05-17T01:15:41Z",
"published": "2022-05-17T01:15:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-5195"
},
{
"type": "WEB",
"url": "https://bugs.launchpad.net/unity/7.2/+bug/1349128"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/95199"
},
{
"type": "WEB",
"url": "http://www.osvdb.org/109788"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/68987"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-2303-1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6WRG-Q4HC-HRW5
Vulnerability from github – Published: 2022-11-10 12:01 – Updated: 2022-11-10 12:01Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-41039, CVE-2022-41088.
{
"affected": [],
"aliases": [
"CVE-2022-41044"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-09T22:15:00Z",
"severity": "HIGH"
},
"details": "Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-41039, CVE-2022-41088.",
"id": "GHSA-6wrg-q4hc-hrw5",
"modified": "2022-11-10T12:01:08Z",
"published": "2022-11-10T12:01:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41044"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-41044"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-41044"
}
],
"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-6WV7-FPG8-F44Q
Vulnerability from github – Published: 2022-05-13 01:13 – Updated: 2022-05-13 01:13Race condition in PolicyKit (aka polkit) allows local users to bypass intended PolicyKit restrictions and gain privileges by starting a setuid or pkexec process before the authorization check is performed, related to (1) the polkit_unix_process_new API function, (2) the dbus API, or (3) the --process (unix-process) option for authorization to pkcheck.
{
"affected": [],
"aliases": [
"CVE-2013-4288"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-10-03T21:55:00Z",
"severity": "HIGH"
},
"details": "Race condition in PolicyKit (aka polkit) allows local users to bypass intended PolicyKit restrictions and gain privileges by starting a setuid or pkexec process before the authorization check is performed, related to (1) the polkit_unix_process_new API function, (2) the dbus API, or (3) the --process (unix-process) option for authorization to pkcheck.",
"id": "GHSA-6wv7-fpg8-f44q",
"modified": "2022-05-13T01:13:29Z",
"published": "2022-05-13T01:13:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4288"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2013:1270"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2013-4288"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1002375"
},
{
"type": "WEB",
"url": "http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1002375"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2013-10/msg00004.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2013-10/msg00005.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2013-10/msg00062.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2013-11/msg00000.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2013-1270.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2013-1460.html"
},
{
"type": "WEB",
"url": "http://seclists.org/oss-sec/2013/q3/626"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2013/09/18/4"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-1953-1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6WXF-7784-62FP
Vulnerability from github – Published: 2025-03-07 20:00 – Updated: 2025-03-07 20:00Horcrux Incident Disclosure: Possible Double-Sign
Summary
On March 6, 2025, a Horcrux user (01node) experienced a double-signing incident on the Osmosis network, resulting in a 5% slash penalty (approximately 75,000 OSMO or $20,000 USD). After thorough investigation, we have identified a race condition in Horcrux's signature state handling as the root cause. This vulnerability was introduced in July 2023 as part of PR #169 and affects all Horcrux versions from v3.1.0 through v3.3.1. A fix has been developed and is being deployed immediately.
Probability
The bug has an extremely low probability of occurrence, affecting one validator out of hundreds that have been using the affected software versions to validate over the past few years. In the added tests, the probability on typical hardware is in the range of 1 in 1 billion per signed vote due to the root cause needing two independent events to occur within approximately the same microsecond duration.
Severity
While rare, it is of high severity, as the double-sign (tombstone) slash on most Cosmos chains is typically 5% to the validator’s self stake and the stake of delegators that is delegated to the validator. The bug is not exploitable, so the urgency to apply this patch is purely around avoiding the race condition to remove tombstone risk.
Impact
- One known validator (01node) was affected
- The validator and its delegators were slashed 5% of their stake delegated with the validator (\~75,000 OSMO, \~$20,000 USD)
- The incident occurred at Osmosis block height 30968345
Technical Details
Root Cause
The issue was a race condition in the signature state handling code. When two sign requests arrive nearly simultaneously for the same Height-Round-Step (HRS), a split read-write lock pattern allowed both to proceed when they should have been serialized. This vulnerability allowed Horcrux to sign both a "yes" vote (non-nil BlockID) and a "no" vote (nil BlockID) for the same block, which constitutes a double sign violation.
In the affected code:
- The
HRSKey()method used a read lock to check the current signature state - The
cacheAndMarshal()method used a separate write lock to update the state
Because the usage of these operations unlocked in the middle to perform checks rather than occurring under a single lock, they were not atomic. Very rarely, two concurrent signature requests could both pass the initial safety check before either one updated the state, leading to a double signature.
Evidence from logs shows two different signatures were produced within 1.5 milliseconds of each other:
DuplicateVoteEvidence{
VoteA: Vote{69:03C016AB7EC3 30968345/00/SIGNED_MSG_TYPE_PREVOTE(Prevote) 000000000000 BEEB4E1F5432 000000000000 @ 2025-03-06T21:35:48.759070033Z},
VoteB: Vote{69:03C016AB7EC3 30968345/00/SIGNED_MSG_TYPE_PREVOTE(Prevote) 817EB28D720F FAE04CB3CF89 000000000000 @ 2025-03-06T21:35:48.760639069Z}
}
This matches the signatures reported in the Horcrux cosigner logs:
- Cosigner-1:
sig=FAE04CB3CF89 ts="2025-03-06 21:35:48.760639069 +0000 UTC" - Cosigner-2:
sig=BEEB4E1F5432 ts="2025-03-06 21:35:48.759070033 +0000 UTC"
The race condition allowed both signatures to be validated and broadcast, resulting in the double sign.
Fix
The fix implements a single mutex lock that covers both the reading of the current signature state and the subsequent writing of any updates:
func (signState *SignState) Save(
ssc SignStateConsensus,
pendingDiskWG *sync.WaitGroup,
) error {
signState.mu.Lock()
if err := signState.getErrorIfLessOrEqual(ssc.Height, ssc.Round, ssc.Step); err != nil {
signState.mu.Unlock()
return err
}
// HRS is greater than existing state, move forward with caching and saving.
signState.cache[ssc.HRSKey()] = ssc
// Update state
// ...
signStateCopy := signState.copy()
signState.mu.Unlock()
// Perform disk operations
// ...
}
By using a single lock for both operations, we ensure that only one signature request for a given HRS can proceed at a time, eliminating the race condition.
Timeline
- July 6, 2023: Vulnerability introduced in PR #169 "sign state signaling"
- March 6, 2025, \~21:35 UTC: 01node double-sign occurred at Osmosis block height 30968345
- March 6, 2025, \~23:25 UTC: 01node reported the incident
- March 7, 2025, \~1:03 UTC: Root cause identified and fix developed
- March 7, 2025: Fix released and deployed (planned)
Recommendations
All Horcrux users running versions v3.1.0 through v3.3.1 should update to the patched version immediately. The fix is backward compatible and does not require any configuration changes.
Update instructions:
- Download the v3.3.2 release binary or container image, or build from source on the v3.3.2 tag
- Apply the release binary or image to your deployment
- Restart your cosigner processes one at a time to ensure continuous validator operation
Preventive Measures
To prevent similar issues in the future, we are implementing the following measures:
- Adding additional tests focused on concurrent signature requests
- Implementing a comprehensive review of all critical-path mutex usage in the codebase
- Adding additional logging and monitoring for potential double-sign conditions
- Enhancing the code review process for security-critical components
Conclusion
We deeply regret this incident and the impact it has had on affected validators. Horcrux was specifically designed to prevent double-signing, and we take this failure extremely seriously. We are committed to making all necessary improvements to ensure this type of incident cannot occur again.
Strangelove is in direct communication with affected parties and will provide any assistance needed, including detailed technical information about the incident and remediation steps.
We will be working with 01node to reimburse those impacted by the tombstone event slash.
For any questions or concerns regarding this incident, please contact security@strange.love.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/strangelove-ventures/horcrux/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.1.0"
},
{
"fixed": "3.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-07T20:00:01Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# **Horcrux Incident Disclosure: Possible Double-Sign**\n\n## **Summary**\n\nOn March 6, 2025, a Horcrux user (01node) experienced a double-signing incident on the Osmosis network, resulting in a 5% slash penalty (approximately 75,000 OSMO or $20,000 USD). After thorough investigation, we have identified a race condition in Horcrux\u0027s signature state handling as the root cause. This vulnerability was introduced in July 2023 as part of PR [\\#169](https://github.com/strangelove-ventures/horcrux/pull/169) and affects all Horcrux versions from v3.1.0 through v3.3.1. A fix has been developed and is being deployed immediately.\n\n## **Probability**\n\nThe bug has an extremely low probability of occurrence, affecting one validator out of hundreds that have been using the affected software versions to validate over the past few years. In the added tests, the probability on typical hardware is in the range of 1 in 1 billion per signed vote due to the root cause needing two independent events to occur within approximately the same microsecond duration.\n\n## **Severity**\n\nWhile rare, it is of high severity, as the double-sign (tombstone) slash on most Cosmos chains is typically 5% to the validator\u2019s self stake and the stake of delegators that is delegated to the validator. The bug is not exploitable, so the urgency to apply this patch is purely around avoiding the race condition to remove tombstone risk.\n\n## **Impact**\n\n* One known validator (01node) was affected \n* The validator and its delegators were slashed 5% of their stake delegated with the validator (\\~75,000 OSMO, \\~$20,000 USD) \n* The incident occurred at Osmosis block height 30968345\n\n## **Technical Details**\n\n### **Root Cause**\n\nThe issue was a race condition in the signature state handling code. When two sign requests arrive nearly simultaneously for the same Height-Round-Step (HRS), a split read-write lock pattern allowed both to proceed when they should have been serialized. This vulnerability allowed Horcrux to sign both a \"yes\" vote (non-nil BlockID) and a \"no\" vote (nil BlockID) for the same block, which constitutes a double sign violation.\n\nIn the affected code:\n\n1. The `HRSKey()` method used a read lock to check the current signature state \n2. The `cacheAndMarshal()` method used a separate write lock to update the state\n\nBecause the usage of these operations unlocked in the middle to perform checks rather than occurring under a single lock, they were not atomic. Very rarely, two concurrent signature requests could both pass the initial safety check before either one updated the state, leading to a double signature.\n\nEvidence from logs shows two different signatures were produced within 1.5 milliseconds of each other:\n\n```\nDuplicateVoteEvidence{\n VoteA: Vote{69:03C016AB7EC3 30968345/00/SIGNED_MSG_TYPE_PREVOTE(Prevote) 000000000000 BEEB4E1F5432 000000000000 @ 2025-03-06T21:35:48.759070033Z}, \n VoteB: Vote{69:03C016AB7EC3 30968345/00/SIGNED_MSG_TYPE_PREVOTE(Prevote) 817EB28D720F FAE04CB3CF89 000000000000 @ 2025-03-06T21:35:48.760639069Z}\n}\n```\n\nThis matches the signatures reported in the Horcrux cosigner logs:\n\n* Cosigner-1: `sig=FAE04CB3CF89 ts=\"2025-03-06 21:35:48.760639069 +0000 UTC\"` \n* Cosigner-2: `sig=BEEB4E1F5432 ts=\"2025-03-06 21:35:48.759070033 +0000 UTC\"`\n\nThe race condition allowed both signatures to be validated and broadcast, resulting in the double sign.\n\n### **Fix**\n\nThe fix implements a single mutex lock that covers both the reading of the current signature state and the subsequent writing of any updates:\n\n```go\nfunc (signState *SignState) Save(\n\tssc SignStateConsensus,\n\tpendingDiskWG *sync.WaitGroup,\n) error {\n\tsignState.mu.Lock()\n\tif err := signState.getErrorIfLessOrEqual(ssc.Height, ssc.Round, ssc.Step); err != nil {\n\t\tsignState.mu.Unlock()\n\t\treturn err\n\t}\n\n\t// HRS is greater than existing state, move forward with caching and saving.\n\tsignState.cache[ssc.HRSKey()] = ssc\n\t\n\t// Update state\n\t// ...\n\t\n\tsignStateCopy := signState.copy()\n\tsignState.mu.Unlock()\n\t\n\t// Perform disk operations\n\t// ...\n}\n```\n\nBy using a single lock for both operations, we ensure that only one signature request for a given HRS can proceed at a time, eliminating the race condition.\n\n## **Timeline**\n\n* **July 6, 2023**: Vulnerability introduced in PR \\#169 \"sign state signaling\" \n* **March 6, 2025, \\~21:35 UTC**: 01node double-sign occurred at Osmosis block height 30968345 \n* **March 6, 2025, \\~23:25 UTC**: 01node reported the incident \n* **March 7, 2025, \\~1:03 UTC**: Root cause identified and fix developed \n* **March 7, 2025**: Fix released and deployed (planned)\n\n## **Recommendations**\n\nAll Horcrux users running versions v3.1.0 through v3.3.1 should update to the patched version immediately. The fix is backward compatible and does not require any configuration changes.\n\nUpdate instructions:\n\n1. Download the v3.3.2 release binary or container image, or build from source on the v3.3.2 tag \n2. Apply the release binary or image to your deployment \n3. Restart your cosigner processes one at a time to ensure continuous validator operation\n\n## **Preventive Measures**\n\nTo prevent similar issues in the future, we are implementing the following measures:\n\n1. Adding additional tests focused on concurrent signature requests \n2. Implementing a comprehensive review of all critical-path mutex usage in the codebase \n3. Adding additional logging and monitoring for potential double-sign conditions \n4. Enhancing the code review process for security-critical components\n\n## **Conclusion**\n\nWe deeply regret this incident and the impact it has had on affected validators. Horcrux was specifically designed to prevent double-signing, and we take this failure extremely seriously. We are committed to making all necessary improvements to ensure this type of incident cannot occur again.\n\nStrangelove is in direct communication with affected parties and will provide any assistance needed, including detailed technical information about the incident and remediation steps.\n\nWe will be working with 01node to reimburse those impacted by the tombstone event slash.\n\nFor any questions or concerns regarding this incident, please contact [security@strange.love](mailto:security@strange.love).",
"id": "GHSA-6wxf-7784-62fp",
"modified": "2025-03-07T20:00:02Z",
"published": "2025-03-07T20:00:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/strangelove-ventures/horcrux/security/advisories/GHSA-6wxf-7784-62fp"
},
{
"type": "WEB",
"url": "https://github.com/strangelove-ventures/horcrux/pull/169"
},
{
"type": "WEB",
"url": "https://github.com/strangelove-ventures/horcrux/commit/fb49be9baed30942b81b42da2b4f7040a2a83c02"
},
{
"type": "PACKAGE",
"url": "https://github.com/strangelove-ventures/horcrux"
},
{
"type": "WEB",
"url": "https://github.com/strangelove-ventures/horcrux/releases/tag/v3.3.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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/E:A",
"type": "CVSS_V4"
}
],
"summary": "Horcrux Double Sign Possibility"
}
GHSA-6XWW-266G-3F8V
Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2023-02-03 21:30An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges by leveraging a page-writability race condition during addition of a passed-through PCI device.
{
"affected": [],
"aliases": [
"CVE-2019-17341"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-08T01:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges by leveraging a page-writability race condition during addition of a passed-through PCI device.",
"id": "GHSA-6xww-266g-3f8v",
"modified": "2023-02-03T21:30:27Z",
"published": "2022-05-24T16:58:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17341"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2020/Jan/21"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4602"
},
{
"type": "WEB",
"url": "https://xenbits.xen.org/xsa/advisory-285.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/10/25/6"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-285.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6XX3-RG99-GC3P
Vulnerability from github – Published: 2021-08-13 15:22 – Updated: 2025-07-17 22:05Bouncy Castle BC Java before 1.66, BC C# .NET before 1.8.7, BC-FJA before 1.0.2.1, BC before 1.66, BC-FNA before 1.0.1.1 have a timing issue within the EC math library that can expose information about the private key when an attacker is able to observe timing information for the generation of multiple deterministic ECDSA signatures.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.2"
},
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bc-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-ext-jdk15on"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.66"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-ext-jdk16"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.66"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.66"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.66"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15on"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.66"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.66"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk16"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.66"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "BouncyCastle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-15522"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-21T17:50:36Z",
"nvd_published_at": "2021-05-20T12:15:00Z",
"severity": "MODERATE"
},
"details": "Bouncy Castle BC Java before 1.66, BC C# .NET before 1.8.7, BC-FJA before 1.0.2.1, BC before 1.66, BC-FNA before 1.0.1.1 have a timing issue within the EC math library that can expose information about the private key when an attacker is able to observe timing information for the generation of multiple deterministic ECDSA signatures.",
"id": "GHSA-6xx3-rg99-gc3p",
"modified": "2025-07-17T22:05:07Z",
"published": "2021-08-13T15:22:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15522"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-csharp/wiki/CVE-2020-15522"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE-2020-15522"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210622-0007"
},
{
"type": "WEB",
"url": "https://www.bouncycastle.org/releasenotes.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Timing based private key exposure in Bouncy Castle"
}
GHSA-723H-88PX-6CJC
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-01-13 18:31Concurrent execution using shared resource with improper synchronization ('race condition') in Windows SMB Server allows an authorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2026-20926"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T18:16:19Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows SMB Server allows an authorized attacker to elevate privileges over a network.",
"id": "GHSA-723h-88px-6cjc",
"modified": "2026-01-13T18:31:10Z",
"published": "2026-01-13T18:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20926"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20926"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-72GH-33G3-Q3VW
Vulnerability from github – Published: 2022-05-17 05:25 – Updated: 2024-03-21 03:33** DISPUTED ** Race condition in McAfee Total Protection 2010 10.0.580 on Windows XP allows local users to bypass kernel-mode hook handlers, and execute dangerous code that would otherwise be blocked by a handler but not blocked by signature-based malware detection, via certain user-space memory changes during hook-handler execution, aka an argument-switch attack or a KHOBE attack. NOTE: this issue is disputed by some third parties because it is a flaw in a protection mechanism for situations where a crafted program has already begun to execute.
{
"affected": [],
"aliases": [
"CVE-2010-5166"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-08-25T21:55:00Z",
"severity": "MODERATE"
},
"details": "** DISPUTED ** Race condition in McAfee Total Protection 2010 10.0.580 on Windows XP allows local users to bypass kernel-mode hook handlers, and execute dangerous code that would otherwise be blocked by a handler but not blocked by signature-based malware detection, via certain user-space memory changes during hook-handler execution, aka an argument-switch attack or a KHOBE attack. NOTE: this issue is disputed by some third parties because it is a flaw in a protection mechanism for situations where a crafted program has already begun to execute.",
"id": "GHSA-72gh-33g3-q3vw",
"modified": "2024-03-21T03:33:10Z",
"published": "2022-05-17T05:25:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-5166"
},
{
"type": "WEB",
"url": "http://archives.neohapsis.com/archives/bugtraq/2010-05/0026.html"
},
{
"type": "WEB",
"url": "http://archives.neohapsis.com/archives/fulldisclosure/2010-05/0066.html"
},
{
"type": "WEB",
"url": "http://countermeasures.trendmicro.eu/you-just-cant-trust-a-drunk"
},
{
"type": "WEB",
"url": "http://matousec.com/info/advisories/khobe-8.0-earthquake-for-windows-desktop-security-software.php"
},
{
"type": "WEB",
"url": "http://matousec.com/info/articles/khobe-8.0-earthquake-for-windows-desktop-security-software.php"
},
{
"type": "WEB",
"url": "http://www.f-secure.com/weblog/archives/00001949.html"
},
{
"type": "WEB",
"url": "http://www.osvdb.org/67660"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/39924"
},
{
"type": "WEB",
"url": "http://www.theregister.co.uk/2010/05/07/argument_switch_av_bypass"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-72H5-35JC-JQ88
Vulnerability from github – Published: 2022-05-01 23:41 – Updated: 2022-05-01 23:41Race condition in the create_lockpath function in policyd-weight 0.1.14 beta-16 allows local users to modify or delete arbitrary files by creating the LOCKPATH directory, then modifying it after the symbolic link check occurs. NOTE: this is due to an incomplete fix for CVE-2008-1569.
{
"affected": [],
"aliases": [
"CVE-2008-1570"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-03-31T22:44:00Z",
"severity": "MODERATE"
},
"details": "Race condition in the create_lockpath function in policyd-weight 0.1.14 beta-16 allows local users to modify or delete arbitrary files by creating the LOCKPATH directory, then modifying it after the symbolic link check occurs. NOTE: this is due to an incomplete fix for CVE-2008-1569.",
"id": "GHSA-72h5-35jc-jq88",
"modified": "2022-05-01T23:41:24Z",
"published": "2022-05-01T23:41:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-1570"
},
{
"type": "WEB",
"url": "https://bugs.gentoo.org/show_bug.cgi?id=214403"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/41570"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/29738"
},
{
"type": "WEB",
"url": "http://security.gentoo.org/glsa/glsa-200804-11.xml"
},
{
"type": "WEB",
"url": "http://www.osvdb.org/43888"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.