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.
2921 vulnerabilities reference this CWE, most recent first.
GHSA-J563-GW8P-23MQ
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-06-03 18:55In the Linux kernel, the following vulnerability has been resolved:
net: phy: qcom: at803x: fix kernel panic with at8031_probe
On reworking and splitting the at803x driver, in splitting function of at803x PHYs it was added a NULL dereference bug where priv is referenced before it's actually allocated and then is tried to write to for the is_1000basex and is_fiber variables in the case of at8031, writing on the wrong address.
Fix this by correctly setting priv local variable only after at803x_probe is called and actually allocates priv in the phydev struct.
{
"affected": [],
"aliases": [
"CVE-2024-26942"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: qcom: at803x: fix kernel panic with at8031_probe\n\nOn reworking and splitting the at803x driver, in splitting function of\nat803x PHYs it was added a NULL dereference bug where priv is referenced\nbefore it\u0027s actually allocated and then is tried to write to for the\nis_1000basex and is_fiber variables in the case of at8031, writing on\nthe wrong address.\n\nFix this by correctly setting priv local variable only after\nat803x_probe is called and actually allocates priv in the phydev struct.",
"id": "GHSA-j563-gw8p-23mq",
"modified": "2024-06-03T18:55:50Z",
"published": "2024-05-01T06:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26942"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a4aee277740d04ac0fd54cfa17cc28261932ddc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8a296ad9957b845b89bcf48be1cf8c74875ecc3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J572-WHP3-F4JX
Vulnerability from github – Published: 2022-05-13 01:15 – Updated: 2022-05-13 01:15Race condition in win32k.sys in the kernel-mode drivers in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, and R2 SP1, and Windows 7 Gold and SP1 allows local users to gain privileges, and consequently read the contents of arbitrary kernel memory locations, via a crafted application, a different vulnerability than other CVEs listed in MS13-016.
{
"affected": [],
"aliases": [
"CVE-2013-1263"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-02-13T12:04:00Z",
"severity": "MODERATE"
},
"details": "Race condition in win32k.sys in the kernel-mode drivers in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, and R2 SP1, and Windows 7 Gold and SP1 allows local users to gain privileges, and consequently read the contents of arbitrary kernel memory locations, via a crafted application, a different vulnerability than other CVEs listed in MS13-016.",
"id": "GHSA-j572-whp3-f4jx",
"modified": "2022-05-13T01:15:45Z",
"published": "2022-05-13T01:15:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-1263"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-016"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A16342"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/cas/techalerts/TA13-043B.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J5C6-H3MG-24RJ
Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2025-12-02 03:31In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix race on port output
assume the following setup on a single machine: 1. An openvswitch instance with one bridge and default flows 2. two network namespaces "server" and "client" 3. two ovs interfaces "server" and "client" on the bridge 4. for each ovs interface a veth pair with a matching name and 32 rx and tx queues 5. move the ends of the veth pairs to the respective network namespaces 6. assign ip addresses to each of the veth ends in the namespaces (needs to be the same subnet) 7. start some http server on the server network namespace 8. test if a client in the client namespace can reach the http server
when following the actions below the host has a chance of getting a cpu stuck in a infinite loop: 1. send a large amount of parallel requests to the http server (around 3000 curls should work) 2. in parallel delete the network namespace (do not delete interfaces or stop the server, just kill the namespace)
there is a low chance that this will cause the below kernel cpu stuck message. If this does not happen just retry. Below there is also the output of bpftrace for the functions mentioned in the output.
The series of events happening here is:
1. the network namespace is deleted calling
unregister_netdevice_many_notify somewhere in the process
2. this sets first NETREG_UNREGISTERING on both ends of the veth and
then runs synchronize_net
3. it then calls call_netdevice_notifiers with NETDEV_UNREGISTER
4. this is then handled by dp_device_event which calls
ovs_netdev_detach_dev (if a vport is found, which is the case for
the veth interface attached to ovs)
5. this removes the rx_handlers of the device but does not prevent
packages to be sent to the device
6. dp_device_event then queues the vport deletion to work in
background as a ovs_lock is needed that we do not hold in the
unregistration path
7. unregister_netdevice_many_notify continues to call
netdev_unregister_kobject which sets real_num_tx_queues to 0
8. port deletion continues (but details are not relevant for this issue)
9. at some future point the background task deletes the vport
If after 7. but before 9. a packet is send to the ovs vport (which is
not deleted at this point in time) which forwards it to the
dev_queue_xmit flow even though the device is unregistering.
In skb_tx_hash (which is called in the dev_queue_xmit) path there is
a while loop (if the packet has a rx_queue recorded) that is infinite if
dev->real_num_tx_queues is zero.
To prevent this from happening we update do_output to handle devices
without carrier the same as if the device is not found (which would
be the code path after 9. is done).
Additionally we now produce a warning in skb_tx_hash if we will hit
the infinite loop.
bpftrace (first word is function name):
__dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1 netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1 dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2 ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2 netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 dp_ ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-53188"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T14:15:41Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix race on port output\n\nassume the following setup on a single machine:\n1. An openvswitch instance with one bridge and default flows\n2. two network namespaces \"server\" and \"client\"\n3. two ovs interfaces \"server\" and \"client\" on the bridge\n4. for each ovs interface a veth pair with a matching name and 32 rx and\n tx queues\n5. move the ends of the veth pairs to the respective network namespaces\n6. assign ip addresses to each of the veth ends in the namespaces (needs\n to be the same subnet)\n7. start some http server on the server network namespace\n8. test if a client in the client namespace can reach the http server\n\nwhen following the actions below the host has a chance of getting a cpu\nstuck in a infinite loop:\n1. send a large amount of parallel requests to the http server (around\n 3000 curls should work)\n2. in parallel delete the network namespace (do not delete interfaces or\n stop the server, just kill the namespace)\n\nthere is a low chance that this will cause the below kernel cpu stuck\nmessage. If this does not happen just retry.\nBelow there is also the output of bpftrace for the functions mentioned\nin the output.\n\nThe series of events happening here is:\n1. the network namespace is deleted calling\n `unregister_netdevice_many_notify` somewhere in the process\n2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and\n then runs `synchronize_net`\n3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`\n4. this is then handled by `dp_device_event` which calls\n `ovs_netdev_detach_dev` (if a vport is found, which is the case for\n the veth interface attached to ovs)\n5. this removes the rx_handlers of the device but does not prevent\n packages to be sent to the device\n6. `dp_device_event` then queues the vport deletion to work in\n background as a ovs_lock is needed that we do not hold in the\n unregistration path\n7. `unregister_netdevice_many_notify` continues to call\n `netdev_unregister_kobject` which sets `real_num_tx_queues` to 0\n8. port deletion continues (but details are not relevant for this issue)\n9. at some future point the background task deletes the vport\n\nIf after 7. but before 9. a packet is send to the ovs vport (which is\nnot deleted at this point in time) which forwards it to the\n`dev_queue_xmit` flow even though the device is unregistering.\nIn `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there is\na while loop (if the packet has a rx_queue recorded) that is infinite if\n`dev-\u003ereal_num_tx_queues` is zero.\n\nTo prevent this from happening we update `do_output` to handle devices\nwithout carrier the same as if the device is not found (which would\nbe the code path after 9. is done).\n\nAdditionally we now produce a warning in `skb_tx_hash` if we will hit\nthe infinite loop.\n\nbpftrace (first word is function name):\n\n__dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1\nnetdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1\ndp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1\nsynchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024\nsynchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024\nsynchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024\nsynchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024\ndp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2\novs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2\nnetdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2\nsynchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024\nnetdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2\ndp_\n---truncated---",
"id": "GHSA-j5c6-h3mg-24rj",
"modified": "2025-12-02T03:31:35Z",
"published": "2025-09-15T15:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53188"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/066b86787fa3d97b7aefb5ac0a99a22dad2d15f8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/284be5db6c8d06d247ed056cfc448c4f79bbb16c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56252da41426f3d01957456f13caf46ce670ea29"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5efcb301523baacd98a47553d4996e924923114d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/644b3051b06ba465bc7401bfae9b14963cbc8c1c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b0dd09c1ceb35950d2884848099fccc9ec9a123"
}
],
"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-J5FX-9H45-WV8Q
Vulnerability from github – Published: 2022-05-13 01:15 – Updated: 2022-05-13 01:15Race condition in win32k.sys in the kernel-mode drivers in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, and R2 SP1, and Windows 7 Gold and SP1 allows local users to gain privileges, and consequently read the contents of arbitrary kernel memory locations, via a crafted application, a different vulnerability than other CVEs listed in MS13-016.
{
"affected": [],
"aliases": [
"CVE-2013-1267"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-02-13T12:04:00Z",
"severity": "MODERATE"
},
"details": "Race condition in win32k.sys in the kernel-mode drivers in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, and R2 SP1, and Windows 7 Gold and SP1 allows local users to gain privileges, and consequently read the contents of arbitrary kernel memory locations, via a crafted application, a different vulnerability than other CVEs listed in MS13-016.",
"id": "GHSA-j5fx-9h45-wv8q",
"modified": "2022-05-13T01:15:46Z",
"published": "2022-05-13T01:15:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-1267"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-016"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A16412"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/cas/techalerts/TA13-043B.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J5GJ-G4CC-754W
Vulnerability from github – Published: 2023-04-06 18:30 – Updated: 2023-04-12 21:30In display drm, there is a possible double free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07570826; Issue ID: ALPS07570826.
{
"affected": [],
"aliases": [
"CVE-2023-20686"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-06T18:15:00Z",
"severity": "MODERATE"
},
"details": "In display drm, there is a possible double free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07570826; Issue ID: ALPS07570826.",
"id": "GHSA-j5gj-g4cc-754w",
"modified": "2023-04-12T21:30:20Z",
"published": "2023-04-06T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20686"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/April-2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J5GQ-897M-2RFF
Vulnerability from github – Published: 2025-12-10 21:31 – Updated: 2025-12-10 21:31Description
In the Okta Java SDK, race conditions may arise from concurrent requests using the ApiClient class. This could cause a status code or response header from one request’s response to influence another request’s response.
Affected product and versions
You may be affected if you meet the following preconditions: - Using the Okta Java SDK between versions 11.0.0 and 20.0.0, and - Implementing a multithreaded application with the ApiClient class where the response status code is used in access control flows
Resolution
Upgrade Okta/okta-sdk-java to versions 21.0.0 or greater.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 20.0.0"
},
"package": {
"ecosystem": "Maven",
"name": "com.okta.sdk:okta-sdk-root"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "20.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-67505"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-10T21:31:52Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Description\nIn the Okta Java SDK, race conditions may arise from concurrent requests using the ApiClient class. This could cause a status code or response header from one request\u2019s response to influence another request\u2019s response.\n\n\n### Affected product and versions\nYou may be affected if you meet the following preconditions:\n- Using the Okta Java SDK between versions 11.0.0 and 20.0.0, and\n- Implementing a multithreaded application with the ApiClient class where the response status code is used in access control flows\n\n### Resolution\nUpgrade Okta/okta-sdk-java to versions 21.0.0 or greater.",
"id": "GHSA-j5gq-897m-2rff",
"modified": "2025-12-10T21:31:52Z",
"published": "2025-12-10T21:31:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/okta/okta-sdk-java/security/advisories/GHSA-j5gq-897m-2rff"
},
{
"type": "WEB",
"url": "https://github.com/okta/okta-sdk-java/commit/abf4f128a0441f90cb7efcdcf4bde1aef8703243"
},
{
"type": "PACKAGE",
"url": "https://github.com/okta/okta-sdk-java"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Race condition in the Okta Java SDK"
}
GHSA-J5V2-R4PG-J7H4
Vulnerability from github – Published: 2024-05-01 15:30 – Updated: 2025-09-18 18:30In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix race when detecting delalloc ranges during fiemap
For fiemap we recently stopped locking the target extent range for the whole duration of the fiemap call, in order to avoid a deadlock in a scenario where the fiemap buffer happens to be a memory mapped range of the same file. This use case is very unlikely to be useful in practice but it may be triggered by fuzz testing (syzbot, etc).
This however introduced a race that makes us miss delalloc ranges for file regions that are currently holes, so the caller of fiemap will not be aware that there's data for some file regions. This can be quite serious for some use cases - for example in coreutils versions before 9.0, the cp program used fiemap to detect holes and data in the source file, copying only regions with data (extents or delalloc) from the source file to the destination file in order to preserve holes (see the documentation for its --sparse command line option). This means that if cp was used with a source file that had delalloc in a hole, the destination file could end up without that data, which is effectively a data loss issue, if it happened to hit the race described below.
The race happens like this:
1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that has delalloc in the file range [64M, 65M[, which is currently a hole;
2) Fiemap locks the inode in shared mode, then starts iterating the inode's subvolume tree searching for file extent items, without having the whole fiemap target range locked in the inode's io tree - the change introduced recently by commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking"). It only locks ranges in the io tree when it finds a hole or prealloc extent since that commit;
3) Note that fiemap clones each leaf before using it, and this is to avoid deadlocks when locking a file range in the inode's io tree and the fiemap buffer is memory mapped to some file, because writing to the page with btrfs_page_mkwrite() will wait on any ordered extent for the page's range and the ordered extent needs to lock the range and may need to modify the same leaf, therefore leading to a deadlock on the leaf;
4) While iterating the file extent items in the cloned leaf before finding the hole in the range [64M, 65M[, the delalloc in that range is flushed and its ordered extent completes - meaning the corresponding file extent item is in the inode's subvolume tree, but not present in the cloned leaf that fiemap is iterating over;
5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in the cloned leaf (or a file extent item with disk_bytenr == 0 in case the NO_HOLES feature is not enabled), it will lock that file range in the inode's io tree and then search for delalloc by checking for the EXTENT_DELALLOC bit in the io tree for that range and ordered extents (with btrfs_find_delalloc_in_range()). But it finds nothing since the delalloc in that range was already flushed and the ordered extent completed and is gone - as a result fiemap will not report that there's delalloc or an extent for the range [64M, 65M[, so user space will be mislead into thinking that there's a hole in that range.
This could actually be sporadically triggered with test case generic/094 from fstests, which reports a missing extent/delalloc range like this:
generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad) --- tests/generic/094.out 2020-06-10 19:29:03.830519425 +0100 +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad 2024-02-28 11:00:00.381071525 +0000 @@ -1,3 +1,9 @@ QA output created by 094 fiemap run with sync fiemap run without sync +ERROR: couldn't find extent at 7 +map is 'HHDDHPPDPHPH' +logical: [ 5.. 6] phys: ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-27080"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T13:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race when detecting delalloc ranges during fiemap\n\nFor fiemap we recently stopped locking the target extent range for the\nwhole duration of the fiemap call, in order to avoid a deadlock in a\nscenario where the fiemap buffer happens to be a memory mapped range of\nthe same file. This use case is very unlikely to be useful in practice but\nit may be triggered by fuzz testing (syzbot, etc).\n\nThis however introduced a race that makes us miss delalloc ranges for\nfile regions that are currently holes, so the caller of fiemap will not\nbe aware that there\u0027s data for some file regions. This can be quite\nserious for some use cases - for example in coreutils versions before 9.0,\nthe cp program used fiemap to detect holes and data in the source file,\ncopying only regions with data (extents or delalloc) from the source file\nto the destination file in order to preserve holes (see the documentation\nfor its --sparse command line option). This means that if cp was used\nwith a source file that had delalloc in a hole, the destination file could\nend up without that data, which is effectively a data loss issue, if it\nhappened to hit the race described below.\n\nThe race happens like this:\n\n1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that\n has delalloc in the file range [64M, 65M[, which is currently a hole;\n\n2) Fiemap locks the inode in shared mode, then starts iterating the\n inode\u0027s subvolume tree searching for file extent items, without having\n the whole fiemap target range locked in the inode\u0027s io tree - the\n change introduced recently by commit b0ad381fa769 (\"btrfs: fix\n deadlock with fiemap and extent locking\"). It only locks ranges in\n the io tree when it finds a hole or prealloc extent since that\n commit;\n\n3) Note that fiemap clones each leaf before using it, and this is to\n avoid deadlocks when locking a file range in the inode\u0027s io tree and\n the fiemap buffer is memory mapped to some file, because writing\n to the page with btrfs_page_mkwrite() will wait on any ordered extent\n for the page\u0027s range and the ordered extent needs to lock the range\n and may need to modify the same leaf, therefore leading to a deadlock\n on the leaf;\n\n4) While iterating the file extent items in the cloned leaf before\n finding the hole in the range [64M, 65M[, the delalloc in that range\n is flushed and its ordered extent completes - meaning the corresponding\n file extent item is in the inode\u0027s subvolume tree, but not present in\n the cloned leaf that fiemap is iterating over;\n\n5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in\n the cloned leaf (or a file extent item with disk_bytenr == 0 in case\n the NO_HOLES feature is not enabled), it will lock that file range in\n the inode\u0027s io tree and then search for delalloc by checking for the\n EXTENT_DELALLOC bit in the io tree for that range and ordered extents\n (with btrfs_find_delalloc_in_range()). But it finds nothing since the\n delalloc in that range was already flushed and the ordered extent\n completed and is gone - as a result fiemap will not report that there\u0027s\n delalloc or an extent for the range [64M, 65M[, so user space will be\n mislead into thinking that there\u0027s a hole in that range.\n\nThis could actually be sporadically triggered with test case generic/094\nfrom fstests, which reports a missing extent/delalloc range like this:\n\n generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad)\n --- tests/generic/094.out\t2020-06-10 19:29:03.830519425 +0100\n +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad\t2024-02-28 11:00:00.381071525 +0000\n @@ -1,3 +1,9 @@\n QA output created by 094\n fiemap run with sync\n fiemap run without sync\n +ERROR: couldn\u0027t find extent at 7\n +map is \u0027HHDDHPPDPHPH\u0027\n +logical: [ 5.. 6] phys:\n---truncated---",
"id": "GHSA-j5v2-r4pg-j7h4",
"modified": "2025-09-18T18:30:21Z",
"published": "2024-05-01T15:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27080"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49d640d2946c35a17b051d54171a032dd95b0f50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/978b63f7464abcfd364a6c95f734282c50f3decf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ced63fffd63072c0ca55d5a451010d71bf08c0b3"
}
],
"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-J5XM-8FGH-W49X
Vulnerability from github – Published: 2026-06-09 18:30 – Updated: 2026-06-09 18:30Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Push Notifications allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-42979"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T17:17:13Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Push Notifications allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-j5xm-8fgh-w49x",
"modified": "2026-06-09T18:30:45Z",
"published": "2026-06-09T18:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42979"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-42979"
}
],
"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-J65R-8HRG-QC6X
Vulnerability from github – Published: 2024-04-09 03:30 – Updated: 2025-11-04 21:31An attacker can make the Node.js HTTP/2 server completely unavailable by sending a small amount of HTTP/2 frames packets with a few HTTP/2 frames inside. It is possible to leave some data in nghttp2 memory after reset when headers with HTTP/2 CONTINUATION frame are sent to the server and then a TCP connection is abruptly closed by the client triggering the Http2Session destructor while header frames are still being processed (and stored in memory) causing a race condition.
{
"affected": [],
"aliases": [
"CVE-2024-27983"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-09T01:15:49Z",
"severity": "HIGH"
},
"details": "An attacker can make the Node.js HTTP/2 server completely unavailable by sending a small amount of HTTP/2 frames packets with a few HTTP/2 frames inside. It is possible to leave some data in nghttp2 memory after reset when headers with HTTP/2 CONTINUATION frame are sent to the server and then a TCP connection is abruptly closed by the client triggering the Http2Session destructor while header frames are still being processed (and stored in memory) causing a race condition.",
"id": "GHSA-j65r-8hrg-qc6x",
"modified": "2025-11-04T21:31:23Z",
"published": "2024-04-09T03:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27983"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2319584"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00029.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JDECX4BYZLMM4S4LALN4DPZ2HUTTPLKE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YDVFUH7ACZPYB3BS4SVILNOY7NQU73VW"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240510-0002"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/421644"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/04/03/16"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J68W-7QM9-FJQQ
Vulnerability from github – Published: 2022-05-13 01:03 – Updated: 2025-11-04 18:30Race condition in mm/gup.c in the Linux kernel 2.x through 4.x before 4.8.3 allows local users to gain privileges by leveraging incorrect handling of a copy-on-write (COW) feature to write to a read-only memory mapping, as exploited in the wild in October 2016, aka "Dirty COW."
{
"affected": [],
"aliases": [
"CVE-2016-5195"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-11-10T21:59:00Z",
"severity": "HIGH"
},
"details": "Race condition in mm/gup.c in the Linux kernel 2.x through 4.x before 4.8.3 allows local users to gain privileges by leveraging incorrect handling of a copy-on-write (COW) feature to write to a read-only memory mapping, as exploited in the wild in October 2016, aka \"Dirty COW.\"",
"id": "GHSA-j68w-7qm9-fjqq",
"modified": "2025-11-04T18:30:34Z",
"published": "2022-05-13T01:03:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-5195"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/E7M62SRP6CZLJ4ZXCRZKV4WPLQBSR7DT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NWMDLBWMGZKFHMRJ7QUQVCERP5QHDB6W"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/W3APRVDVPDBXLH4DC5UKZVCR742MJIM3"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/E7M62SRP6CZLJ4ZXCRZKV4WPLQBSR7DT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NWMDLBWMGZKFHMRJ7QUQVCERP5QHDB6W"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/W3APRVDVPDBXLH4DC5UKZVCR742MJIM3"
},
{
"type": "WEB",
"url": "https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5195.html"
},
{
"type": "WEB",
"url": "https://security-tracker.debian.org/tracker/CVE-2016-5195"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20161025-0001"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2016-5195"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2016-11-01.html"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2016-12-01.html"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181107-vcsd"
},
{
"type": "WEB",
"url": "https://www.arista.com/en/support/advisories-notices/security-advisories/1753-security-advisory-0026"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2016-5195"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/40611"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/40616"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/40839"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/40847"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/243144"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:0372"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/cve-2016-5195"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/vulnerabilities/2706661"
},
{
"type": "WEB",
"url": "https://bto.bluecoat.com/security-advisory/sa134"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1384344"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1004418"
},
{
"type": "WEB",
"url": "https://dirtycow.ninja"
},
{
"type": "WEB",
"url": "https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs"
},
{
"type": "WEB",
"url": "https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-c05352241"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbgn03707en_us"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbgn03722en_us"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbgn03742en_us"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbgn03761en_us"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05341463"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05347541"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05352241"
},
{
"type": "WEB",
"url": "https://help.ecostruxureit.com/display/public/UADCO8x/StruxureWare+Data+Center+Operation+Software+Vulnerability+Fixes"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10176"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10177"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10222"
},
{
"type": "WEB",
"url": "http://fortiguard.com/advisory/FG-IR-16-063"
},
{
"type": "WEB",
"url": "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619"
},
{
"type": "WEB",
"url": "http://kb.juniper.net/InfoCenter/index?page=content\u0026id=JSA10770"
},
{
"type": "WEB",
"url": "http://kb.juniper.net/InfoCenter/index?page=content\u0026id=JSA10774"
},
{
"type": "WEB",
"url": "http://kb.juniper.net/InfoCenter/index?page=content\u0026id=JSA10807"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00034.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00035.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00036.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00038.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00039.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00040.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00045.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00048.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00049.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00050.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00051.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00052.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00053.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00054.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00055.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00056.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00057.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00058.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00063.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00064.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00065.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00066.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00067.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00072.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-12/msg00033.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-12/msg00100.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00041.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/139277/Kernel-Live-Patch-Security-Notice-LSN-0012-1.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/139286/DirtyCow-Linux-Kernel-Race-Condition.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/139287/DirtyCow-Local-Root-Proof-Of-Concept.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/139922/Linux-Kernel-Dirty-COW-PTRACE_POKEDATA-Privilege-Escalation.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/139923/Linux-Kernel-Dirty-COW-PTRACE_POKEDATA-Privilege-Escalation.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/142151/Kernel-Live-Patch-Security-Notice-LSN-0021-1.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2098.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2105.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2106.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2107.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2110.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2118.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2120.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2124.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2126.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2127.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2128.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2132.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2133.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Aug/35"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20161026-linux"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2016/dsa-3696"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20161207-01-dirtycow-en"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.8.3"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/21/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/26/7"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/27/13"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/30/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/11/03/7"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/03/07/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/08/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/08/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/08/7"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/08/8"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/09/4"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/15/1"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/539611/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/540252/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/540344/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/540736/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/archive/1/539611/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/archive/1/540252/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/archive/1/540344/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/archive/1/540736/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/93793"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1037078"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3104-1"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3104-2"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3105-1"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3105-2"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3106-1"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3106-2"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3106-3"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3106-4"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3107-1"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3107-2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/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.