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.
3588 vulnerabilities reference this CWE, most recent first.
GHSA-5W39-288F-6M96
Vulnerability from github – Published: 2026-08-10 15:33 – Updated: 2026-08-23 15:32In the Linux kernel, the following vulnerability has been resolved:
net/sched: serialize qdisc_rtab_list against concurrent get/put
qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees.
That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide.
BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048
Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.
{
"affected": [],
"aliases": [
"CVE-2026-68138"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T13:19:59Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: serialize qdisc_rtab_list against concurrent get/put\n\nqdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly\nlinked list qdisc_rtab_list and a plain non-atomic \u0027int refcnt\u0027 with no\nlock. This was only safe because every caller historically held the RTNL\nmutex, which serialized all rate-table lookups, inserts and frees.\n\nThat invariant no longer holds. cls_flower sets\nTCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false\nfor it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through\ntcf_exts_validate_ex() -\u003e tcf_action_init() -\u003e tcf_action_init_1() -\u003e\ntcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the\nRTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each\nadding a flower filter with a police action carrying the same rate, then\nrace on qdisc_rtab_list and on the non-atomic refcnt, leading to a\nuse-after-free / double-free of the kmalloc-2k struct qdisc_rate_table.\nqdisc_rtab_list is a single global (not per-netns), so the corrupted\nobject is shared system-wide.\n\n BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160\n qdisc_put_rtab+0x12f/0x160\n tcf_police_init+0xda9/0x1590\n tcf_action_init_1+0x460/0x6b0\n tcf_action_init+0x439/0xa40\n tcf_exts_validate_ex+0x42d/0x550\n fl_change+0xddd/0x7da0\n tc_new_tfilter+0xaa7/0x2420\n rtnetlink_rcv_msg+0x95e/0xe90\n which belongs to the cache kmalloc-2k of size 2048\n\nProtect qdisc_rtab_list and the refcount with a dedicated spinlock. The\n(sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before\ntaking the lock; if a concurrent inserter added an identical table in the\nmeantime the freshly allocated one is freed under the lock, so no\nduplicate is leaked. qdisc_put_rtab() now decrements the refcount and\nunlinks under the same lock.",
"id": "GHSA-5w39-288f-6m96",
"modified": "2026-08-23T15:32:56Z",
"published": "2026-08-10T15:33:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68138"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1b050d09dd1a0ddae83bf012cf4956b7a960235f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4131dd0b6f67acddd616ed7c244e1d3eedd46e7b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e0241f6cbb149d926ee8efee2c734fea71452cf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ddc2eb0d2da9c83f54f1e5720525b461b8480c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d981098b76756ed71666a27518eeb69883657c43"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f43ee0c0730d6191629b5ee1ceae27b1ebfdc047"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f93c89392bd3b180b5b7abc6fdae8e3dd667a313"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fb29e1b41052488ee3f2d115d4a870497ebd7f7d"
}
],
"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-5W3W-MCF7-V883
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-08 15:31In the Linux kernel, the following vulnerability has been resolved:
smb: client: prevent races in ->query_interfaces()
It was possible for two query interface works to be concurrently trying to update the interfaces.
Prevent this by checking and updating iface_last_update under iface_lock.
{
"affected": [],
"aliases": [
"CVE-2026-43239"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:44Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: prevent races in -\u003equery_interfaces()\n\nIt was possible for two query interface works to be concurrently trying\nto update the interfaces.\n\nPrevent this by checking and updating iface_last_update under\niface_lock.",
"id": "GHSA-5w3w-mcf7-v883",
"modified": "2026-05-08T15:31:18Z",
"published": "2026-05-06T12:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43239"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6287eefaf21ec805d42f941bd368018cf397a7f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/76cc4faba0343c6db945b8dc75425b33d633e1b8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93e8e3ee165ae4609a1222b516b573837103d2c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab6564f416a6eaf1199200b6100952407b438f7d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3c06e42e1527716c54f3ad2ced6a034b5f3a489"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5WG8-7C9Q-794V
Vulnerability from github – Published: 2021-08-25 20:50 – Updated: 2021-08-19 18:59An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockWriteGuard unsoundness.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "lock_api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-35912"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-19T18:59:40Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockWriteGuard unsoundness.",
"id": "GHSA-5wg8-7c9q-794v",
"modified": "2021-08-19T18:59:40Z",
"published": "2021-08-25T20:50:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35912"
},
{
"type": "WEB",
"url": "https://github.com/Amanieu/parking_lot/pull/262"
},
{
"type": "PACKAGE",
"url": "https://github.com/Amanieu/parking_lot"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0070.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Data races in lock_api"
}
GHSA-5WJP-VC35-7WGQ
Vulnerability from github – Published: 2022-03-11 00:02 – Updated: 2022-03-18 00:01Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042
{
"affected": [],
"aliases": [
"CVE-2022-23040"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-10T20:15:00Z",
"severity": "HIGH"
},
"details": "Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn\u0027t check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042",
"id": "GHSA-5wjp-vc35-7wgq",
"modified": "2022-03-18T00:01:19Z",
"published": "2022-03-11T00:02:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23040"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-396.txt"
}
],
"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-5WJR-9356-4WC8
Vulnerability from github – Published: 2026-10-23 20:54 – Updated: 2026-10-23 20:54Summary
On the multi-threaded runtime, there is a race condition between Interval::poll_tick and the runtime's time driver.
This affects Interval only. Sleep and Timeout are not affected.
Details
In Tokio v1.54.0, a race condition between tokio::time::Interval::poll_tick (including .tick().await) and the runtime time driver can drop an internal timer entry without synchronizing with the driver thread that is firing it. This causes a data race and use-after-free on the timer's waker and task state in safe Rust, leading to assertion panics, task reference-count corruption, or heap memory corruption.
This bug was introduced by https://github.com/tokio-rs/tokio/pull/8458, and it was fixed by https://github.com/tokio-rs/tokio/pull/8692.
Impact
This may lead to crashes and use-after-frees in applications using Interval on a multi-threaded runtime.
Since this issue is known to lead to crashes in production systems, the v1.54.0 release of Tokio has been yanked.
Credits
Thank you to creepycode and carabistouille for reporting this privately using the procedure outlined in our security policy. They both reported the issue independently of each other.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "tokio"
},
"ranges": [
{
"events": [
{
"introduced": "1.54.0"
},
{
"fixed": "1.54.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.54.0"
]
}
],
"aliases": [
"CVE-2026-115567"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-23T20:54:00Z",
"nvd_published_at": "2026-10-23T18:17:21Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nOn the multi-threaded runtime, there is a race condition between `Interval::poll_tick` and the runtime\u0027s time driver.\n\nThis affects `Interval` only. `Sleep` and `Timeout` are **not** affected.\n\n### Details\n\nIn Tokio v1.54.0, a race condition between `tokio::time::Interval::poll_tick` (including `.tick().await`) and the runtime time driver can drop an internal timer entry without synchronizing with the driver thread that is firing it. This causes a data race and use-after-free on the timer\u0027s waker and task state in safe Rust, leading to assertion panics, task reference-count corruption, or heap memory corruption.\n\nThis bug was introduced by https://github.com/tokio-rs/tokio/pull/8458, and it was fixed by https://github.com/tokio-rs/tokio/pull/8692.\n\n### Impact\n\nThis may lead to crashes and use-after-frees in applications using `Interval` on a multi-threaded runtime.\n\nSince this issue is known to lead to crashes in production systems, the v1.54.0 release of Tokio has been yanked.\n\n### Credits\n\nThank you to [creepycode](https://github.com/ByteZ1337) and [carabistouille](https://github.com/carabistouflette) for reporting this privately using the procedure outlined in our security policy. They both reported the issue independently of each other.",
"id": "GHSA-5wjr-9356-4wc8",
"modified": "2026-10-23T20:54:00Z",
"published": "2026-10-23T20:54:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tokio-rs/tokio/security/advisories/GHSA-5wjr-9356-4wc8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-115567"
},
{
"type": "WEB",
"url": "https://github.com/tokio-rs/tokio/pull/8458"
},
{
"type": "WEB",
"url": "https://github.com/tokio-rs/tokio/pull/8692"
},
{
"type": "WEB",
"url": "https://github.com/tokio-rs/tokio/commit/2b4eba7833864c04ecd2f3e5f4a97ff4f6fa28d0"
},
{
"type": "WEB",
"url": "https://github.com/tokio-rs/tokio/commit/5ed619bbaba87357ee5103d71b75e7c84cad99c9"
},
{
"type": "PACKAGE",
"url": "https://github.com/tokio-rs/tokio"
},
{
"type": "WEB",
"url": "https://github.com/tokio-rs/tokio/releases/tag/tokio-1.54.1"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0384.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Tokio: Race condition in `tokio::time::Interval`"
}
GHSA-5WV7-G9F3-6PX6
Vulnerability from github – Published: 2022-05-17 01:23 – Updated: 2022-05-17 01:23Race condition in the client in IBM Tivoli Storage Manager (TSM) 5.4.0.0 through 5.4.3.6, 5.5.0.0 through 5.5.4.3, 6.1.0.0 through 6.1.5.6, 6.2 before 6.2.5.4, 6.3 before 6.3.2.3, 6.4 before 6.4.2.1, and 7.1 before 7.1.1 on UNIX and Linux allows local users to obtain root privileges via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2014-4813"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-02-13T02:59:00Z",
"severity": "MODERATE"
},
"details": "Race condition in the client in IBM Tivoli Storage Manager (TSM) 5.4.0.0 through 5.4.3.6, 5.5.0.0 through 5.5.4.3, 6.1.0.0 through 6.1.5.6, 6.2 before 6.2.5.4, 6.3 before 6.3.2.3, 6.4 before 6.4.2.1, and 7.1 before 7.1.1 on UNIX and Linux allows local users to obtain root privileges via unspecified vectors.",
"id": "GHSA-5wv7-g9f3-6px6",
"modified": "2022-05-17T01:23:15Z",
"published": "2022-05-17T01:23:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-4813"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/95389"
},
{
"type": "WEB",
"url": "http://www-01.ibm.com/support/docview.wss?uid=swg1IT04140"
},
{
"type": "WEB",
"url": "http://www-01.ibm.com/support/docview.wss?uid=swg21695652"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5WWP-3576-JFJC
Vulnerability from github – Published: 2022-05-24 17:14 – Updated: 2022-05-24 17:14An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service or possibly gain privileges because of missing memory barriers in read-write unlock paths. The read-write unlock paths don't contain a memory barrier. On Arm, this means a processor is allowed to re-order the memory access with the preceding ones. In other words, the unlock may be seen by another processor before all the memory accesses within the "critical" section. As a consequence, it may be possible to have a writer executing a critical section at the same time as readers or another writer. In other words, many of the assumptions (e.g., a variable cannot be modified after a check) in the critical sections are not safe anymore. The read-write locks are used in hypercalls (such as grant-table ones), so a malicious guest could exploit the race. For instance, there is a small window where Xen can leak memory if XENMAPSPACE_grant_table is used concurrently. A malicious guest may be able to leak memory, or cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded.
{
"affected": [],
"aliases": [
"CVE-2020-11739"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-04-14T13:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service or possibly gain privileges because of missing memory barriers in read-write unlock paths. The read-write unlock paths don\u0027t contain a memory barrier. On Arm, this means a processor is allowed to re-order the memory access with the preceding ones. In other words, the unlock may be seen by another processor before all the memory accesses within the \"critical\" section. As a consequence, it may be possible to have a writer executing a critical section at the same time as readers or another writer. In other words, many of the assumptions (e.g., a variable cannot be modified after a check) in the critical sections are not safe anymore. The read-write locks are used in hypercalls (such as grant-table ones), so a malicious guest could exploit the race. For instance, there is a small window where Xen can leak memory if XENMAPSPACE_grant_table is used concurrently. A malicious guest may be able to leak memory, or cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded.",
"id": "GHSA-5wwp-3576-jfjc",
"modified": "2022-05-24T17:14:11Z",
"published": "2022-05-24T17:14:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11739"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5M2XRNCHOGGTJQBZQJ7DCV6ZNAKN3LE2"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NVTP4OYHCTRU3ONFJOFJQVNDFB25KLLG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YMAW7D2MP6RE4BFI5BZWOBBWGY3VSOFN"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202005-08"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4723"
},
{
"type": "WEB",
"url": "https://xenbits.xen.org/xsa/advisory-314.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-05/msg00006.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2020/04/14/2"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-314.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-5X22-W79M-34GQ
Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2024-03-21 03:33It was discovered freeradius up to and including version 3.0.19 does not correctly configure logrotate, allowing a local attacker who already has control of the radiusd user to escalate his privileges to root, by tricking logrotate into writing a radiusd-writable file to a directory normally inaccessible by the radiusd user.
{
"affected": [],
"aliases": [
"CVE-2019-10143"
],
"database_specific": {
"cwe_ids": [
"CWE-250",
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-24T17:29:00Z",
"severity": "HIGH"
},
"details": "It was discovered freeradius up to and including version 3.0.19 does not correctly configure logrotate, allowing a local attacker who already has control of the radiusd user to escalate his privileges to root, by tricking logrotate into writing a radiusd-writable file to a directory normally inaccessible by the radiusd user.",
"id": "GHSA-5x22-w79m-34gq",
"modified": "2024-03-21T03:33:40Z",
"published": "2022-05-24T16:46:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10143"
},
{
"type": "WEB",
"url": "https://github.com/FreeRADIUS/freeradius-server/pull/2666"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3353"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:3984"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2019-10143"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1705340"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10143"
},
{
"type": "WEB",
"url": "https://freeradius.org/security"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/A6VKBZAZKJP5QKXDXRKCM2ZPZND3TFAX"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TKODLHHUOVAYENTBP4D3N25ST3Q6LJBP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/A6VKBZAZKJP5QKXDXRKCM2ZPZND3TFAX"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TKODLHHUOVAYENTBP4D3N25ST3Q6LJBP"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/155361/FreeRadius-3.0.19-Logrotate-Privilege-Escalation.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2019/Nov/14"
}
],
"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-5X3P-258G-5RP8
Vulnerability from github – Published: 2026-05-06 21:31 – Updated: 2026-05-07 01:05Race in Speech in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-7960"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T19:16:45Z",
"severity": "MODERATE"
},
"details": "Race in Speech in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-5x3p-258g-5rp8",
"modified": "2026-05-07T01:05:52Z",
"published": "2026-05-06T21:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7960"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/497007825"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5X67-MPX5-H47Q
Vulnerability from github – Published: 2022-05-17 01:09 – Updated: 2022-05-17 01:09Race condition in SuiteCRM before 7.2.3 allows remote attackers to execute arbitrary code. NOTE: this vulnerability exists because of an incomplete fix for CVE-2015-5947.
{
"affected": [],
"aliases": [
"CVE-2015-5948"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-09-06T21:29:00Z",
"severity": "HIGH"
},
"details": "Race condition in SuiteCRM before 7.2.3 allows remote attackers to execute arbitrary code. NOTE: this vulnerability exists because of an incomplete fix for CVE-2015-5947.",
"id": "GHSA-5x67-mpx5-h47q",
"modified": "2022-05-17T01:09:27Z",
"published": "2022-05-17T01:09:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-5948"
},
{
"type": "WEB",
"url": "https://github.com/salesagility/SuiteCRM/issues/333"
},
{
"type": "WEB",
"url": "https://github.com/salesagility/SuiteCRM/commit/b1b3fd61c7697ad2073cd253d31c9462929e7bb5"
},
{
"type": "WEB",
"url": "https://github.com/XiphosResearch/exploits/tree/master/suiteshell"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2015/08/06/6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Mitigation
Use thread-safe capabilities such as the data access abstraction in Spring.
Mitigation
- Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
- Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Mitigation
When using multithreading and operating on shared variables, only use thread-safe functions.
Mitigation
Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
Mitigation
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Mitigation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Mitigation
Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
Mitigation
Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.
CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.