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.
2899 vulnerabilities reference this CWE, most recent first.
GHSA-XC56-V745-V4G3
Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2025-01-14 21:31Race Condition within a Thread vulnerability in iscsi_snapshot_comm_core in Synology DiskStation Manager (DSM) before 6.2.3-25426-3 allows remote attackers to execute arbitrary code via crafted web requests.
{
"affected": [],
"aliases": [
"CVE-2021-26569"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-366"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-12T07:15:00Z",
"severity": "HIGH"
},
"details": "Race Condition within a Thread vulnerability in iscsi_snapshot_comm_core in Synology DiskStation Manager (DSM) before 6.2.3-25426-3 allows remote attackers to execute arbitrary code via crafted web requests.",
"id": "GHSA-xc56-v745-v4g3",
"modified": "2025-01-14T21:31:41Z",
"published": "2022-05-24T17:44:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26569"
},
{
"type": "WEB",
"url": "https://www.synology.com/security/advisory/Synology_SA_20_26"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-21-338"
}
],
"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-XC6W-68H5-XVR5
Vulnerability from github – Published: 2022-05-17 05:24 – Updated: 2024-03-21 03:33** DISPUTED ** Race condition in Security Shield 2010 13.0.16.313 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-5176"
],
"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 Security Shield 2010 13.0.16.313 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-xc6w-68h5-xvr5",
"modified": "2024-03-21T03:33:10Z",
"published": "2022-05-17T05:24:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-5176"
},
{
"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-XCWW-23JC-699X
Vulnerability from github – Published: 2025-09-10 21:30 – Updated: 2025-09-10 21:30A vulnerability was detected in GrandNode up to 2.3.0. The impacted element is an unknown function of the file /checkout/ConfirmOrder/ of the component Voucher Handler. The manipulation of the argument giftvouchercouponcode results in race condition. The attack may be launched remotely. The attack requires a high level of complexity. The exploitability is regarded as difficult. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-10216"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-10T21:15:34Z",
"severity": "LOW"
},
"details": "A vulnerability was detected in GrandNode up to 2.3.0. The impacted element is an unknown function of the file /checkout/ConfirmOrder/ of the component Voucher Handler. The manipulation of the argument giftvouchercouponcode results in race condition. The attack may be launched remotely. The attack requires a high level of complexity. The exploitability is regarded as difficult. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-xcww-23jc-699x",
"modified": "2025-09-10T21:30:19Z",
"published": "2025-09-10T21:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10216"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.323485"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.323485"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.640784"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-XF8V-VF86-4582
Vulnerability from github – Published: 2022-05-17 00:50 – Updated: 2022-05-17 00:50The Windows NetBT Session Services component on Microsoft Windows Server 2008 R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 allows a remote code execution vulnerability when it fails to maintain certain sequencing requirements, aka "NetBIOS Remote Code Execution Vulnerability".
{
"affected": [],
"aliases": [
"CVE-2017-0161"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-09-13T01:29:00Z",
"severity": "HIGH"
},
"details": "The Windows NetBT Session Services component on Microsoft Windows Server 2008 R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 allows a remote code execution vulnerability when it fails to maintain certain sequencing requirements, aka \"NetBIOS Remote Code Execution Vulnerability\".",
"id": "GHSA-xf8v-vf86-4582",
"modified": "2022-05-17T00:50:34Z",
"published": "2022-05-17T00:50:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0161"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-0161"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100728"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1039318"
}
],
"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"
}
]
}
GHSA-XFM9-CV4J-C74M
Vulnerability from github – Published: 2024-03-11 18:31 – Updated: 2025-02-14 18:30In the Linux kernel, the following vulnerability has been resolved:
mm/sparsemem: fix race in accessing memory_section->usage
The below race is observed on a PFN which falls into the device memory region with the system memory configuration where PFN's are such that [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL]. Since normal zone start and end pfn contains the device memory PFN's as well, the compaction triggered will try on the device memory PFN's too though they end up in NOP(because pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections). When from other core, the section mappings are being removed for the ZONE_DEVICE region, that the PFN in question belongs to, on which compaction is currently being operated is resulting into the kernel crash with CONFIG_SPASEMEM_VMEMAP enabled. The crash logs can be seen at [1].
compact_zone() memunmap_pages ------------- --------------- __pageblock_pfn_to_page ...... (a)pfn_valid(): valid_section()//return true (b)__remove_pages()-> sparse_remove_section()-> section_deactivate(): [Free the array ms->usage and set ms->usage = NULL] pfn_section_valid() [Access ms->usage which is NULL]
NOTE: From the above it can be said that the race is reduced to between the pfn_valid()/pfn_section_valid() and the section deactivate with SPASEMEM_VMEMAP enabled.
The commit b943f045a9af("mm/sparse: fix kernel crash with pfn_section_valid check") tried to address the same problem by clearing the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns false thus ms->usage is not accessed.
Fix this issue by the below steps:
a) Clear SECTION_HAS_MEM_MAP before freeing the ->usage.
b) RCU protected read side critical section will either return NULL when SECTION_HAS_MEM_MAP is cleared or can successfully access ->usage.
c) Free the ->usage with kfree_rcu() and set ms->usage = NULL. No attempt will be made to access ->usage after this as the SECTION_HAS_MEM_MAP is cleared thus valid_section() return false.
Thanks to David/Pavan for their inputs on this patch.
[1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/
On Snapdragon SoC, with the mentioned memory configuration of PFN's as [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of issues daily while testing on a device farm.
For this particular issue below is the log. Though the below log is not directly pointing to the pfn_section_valid(){ ms->usage;}, when we loaded this dump on T32 lauterbach tool, it is pointing.
[ 540.578056] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 540.578068] Mem abort info: [ 540.578070] ESR = 0x0000000096000005 [ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits [ 540.578077] SET = 0, FnV = 0 [ 540.578080] EA = 0, S1PTW = 0 [ 540.578082] FSC = 0x05: level 1 translation fault [ 540.578085] Data abort info: [ 540.578086] ISV = 0, ISS = 0x00000005 [ 540.578088] CM = 0, WnR = 0 [ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--) [ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c [ 540.579454] lr : compact_zone+0x994/0x1058 [ 540.579460] sp : ffffffc03579b510 [ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c [ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640 [ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000 [ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140 [ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff [ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001 [ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440 [ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4 [ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-52489"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-11T18:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/sparsemem: fix race in accessing memory_section-\u003eusage\n\nThe below race is observed on a PFN which falls into the device memory\nregion with the system memory configuration where PFN\u0027s are such that\n[ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL]. Since normal zone start and end\npfn contains the device memory PFN\u0027s as well, the compaction triggered\nwill try on the device memory PFN\u0027s too though they end up in NOP(because\npfn_to_online_page() returns NULL for ZONE_DEVICE memory sections). When\nfrom other core, the section mappings are being removed for the\nZONE_DEVICE region, that the PFN in question belongs to, on which\ncompaction is currently being operated is resulting into the kernel crash\nwith CONFIG_SPASEMEM_VMEMAP enabled. The crash logs can be seen at [1].\n\ncompact_zone()\t\t\tmemunmap_pages\n-------------\t\t\t---------------\n__pageblock_pfn_to_page\n ......\n (a)pfn_valid():\n valid_section()//return true\n\t\t\t (b)__remove_pages()-\u003e\n\t\t\t\t sparse_remove_section()-\u003e\n\t\t\t\t section_deactivate():\n\t\t\t\t [Free the array ms-\u003eusage and set\n\t\t\t\t ms-\u003eusage = NULL]\n pfn_section_valid()\n [Access ms-\u003eusage which\n is NULL]\n\nNOTE: From the above it can be said that the race is reduced to between\nthe pfn_valid()/pfn_section_valid() and the section deactivate with\nSPASEMEM_VMEMAP enabled.\n\nThe commit b943f045a9af(\"mm/sparse: fix kernel crash with\npfn_section_valid check\") tried to address the same problem by clearing\nthe SECTION_HAS_MEM_MAP with the expectation of valid_section() returns\nfalse thus ms-\u003eusage is not accessed.\n\nFix this issue by the below steps:\n\na) Clear SECTION_HAS_MEM_MAP before freeing the -\u003eusage.\n\nb) RCU protected read side critical section will either return NULL\n when SECTION_HAS_MEM_MAP is cleared or can successfully access -\u003eusage.\n\nc) Free the -\u003eusage with kfree_rcu() and set ms-\u003eusage = NULL. No\n attempt will be made to access -\u003eusage after this as the\n SECTION_HAS_MEM_MAP is cleared thus valid_section() return false.\n\nThanks to David/Pavan for their inputs on this patch.\n\n[1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/\n\nOn Snapdragon SoC, with the mentioned memory configuration of PFN\u0027s as\n[ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of\nissues daily while testing on a device farm.\n\nFor this particular issue below is the log. Though the below log is\nnot directly pointing to the pfn_section_valid(){ ms-\u003eusage;}, when we\nloaded this dump on T32 lauterbach tool, it is pointing.\n\n[ 540.578056] Unable to handle kernel NULL pointer dereference at\nvirtual address 0000000000000000\n[ 540.578068] Mem abort info:\n[ 540.578070] ESR = 0x0000000096000005\n[ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 540.578077] SET = 0, FnV = 0\n[ 540.578080] EA = 0, S1PTW = 0\n[ 540.578082] FSC = 0x05: level 1 translation fault\n[ 540.578085] Data abort info:\n[ 540.578086] ISV = 0, ISS = 0x00000005\n[ 540.578088] CM = 0, WnR = 0\n[ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--)\n[ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c\n[ 540.579454] lr : compact_zone+0x994/0x1058\n[ 540.579460] sp : ffffffc03579b510\n[ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c\n[ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640\n[ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000\n[ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140\n[ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff\n[ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001\n[ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440\n[ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4\n[ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000\n---truncated---",
"id": "GHSA-xfm9-cv4j-c74m",
"modified": "2025-02-14T18:30:46Z",
"published": "2024-03-11T18:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52489"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.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"
}
]
}
GHSA-XFPM-Q238-HR33
Vulnerability from github – Published: 2022-08-26 00:03 – Updated: 2022-08-31 00:00A race condition was found in the Linux kernel's watch queue due to a missing lock in pipe_resize_ring(). The specific flaw exists within the handling of pipe buffers. The issue results from the lack of proper locking when performing operations on an object. This flaw allows a local user to crash the system or escalate their privileges on the system.
{
"affected": [],
"aliases": [
"CVE-2022-2959"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-25T18:15:00Z",
"severity": "HIGH"
},
"details": "A race condition was found in the Linux kernel\u0027s watch queue due to a missing lock in pipe_resize_ring(). The specific flaw exists within the handling of pipe buffers. The issue results from the lack of proper locking when performing operations on an object. This flaw allows a local user to crash the system or escalate their privileges on the system.",
"id": "GHSA-xfpm-q238-hr33",
"modified": "2022-08-31T00:00:20Z",
"published": "2022-08-26T00:03:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2959"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/189b0ddc245139af81198d1a3637cac74f96e13a"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230214-0005"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-22-1165"
}
],
"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-XG58-PJF6-W895
Vulnerability from github – Published: 2023-09-06 21:32 – Updated: 2024-04-04 07:32A race condition was addressed with improved state handling. This issue is fixed in macOS Ventura 13.5. An app may be able to execute arbitrary code with kernel privileges.
{
"affected": [],
"aliases": [
"CVE-2023-38616"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-06T21:15:13Z",
"severity": "HIGH"
},
"details": "A race condition was addressed with improved state handling. This issue is fixed in macOS Ventura 13.5. An app may be able to execute arbitrary code with kernel privileges.",
"id": "GHSA-xg58-pjf6-w895",
"modified": "2024-04-04T07:32:21Z",
"published": "2023-09-06T21:32:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38616"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213843"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XGVV-W3J6-FCFQ
Vulnerability from github – Published: 2026-04-14 18:30 – Updated: 2026-04-14 18:30Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-26173"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-14T18:16:52Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-xgvv-w3j6-fcfq",
"modified": "2026-04-14T18:30:37Z",
"published": "2026-04-14T18:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26173"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-26173"
}
],
"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-XGX4-4H9W-53PV
Vulnerability from github – Published: 2026-06-04 19:50 – Updated: 2026-06-04 19:50Summary
This report covers the client-triggered DoQ forwarding path in:
dnsproxyv0.81.2(adguard/dnsproxy:v0.81.2)AdGuard Homev0.107.74(adguard/adguardhome:latest, image version labelv0.107.74)
The issue was reproduced on 2026-04-25 with the products configured through
their documented DoQ listener and plain UDP upstream surfaces. The scope is the
internal backend UDP hop created when a DoQ query is forwarded to a udp://
upstream.
On that path, the backend DNS ID is not preserved as an independent source of
entropy. For both products, the backend observer saw dns_id=0 for every
sampled client-triggered query on the tested path. Repeated reruns then showed
the same txid=0 behavior and the same positive source-port oracle on every
sampled run. A separate quoted-port ICMP oracle distinguished the correct
backend UDP source port from a wrong one with a stable, client-visible behavior
change.
Attached evidence:
dnsproxyoracle path onv0.81.2: attachments/artifacts/g03/20260425T141500Z-g03-v0812/summary.txtdnsproxyv0.81.2repeatability: attachments/artifacts/g03/repeatability-v0812.mddnsproxysteering follow-up onv0.81.2: attachments/artifacts/g04/20260425T141900Z-g04-v0812/summary.txtAdGuard Homeoracle path: attachments/artifacts/g05/20260425T113000Z-g05/summary.txt
Root Cause Analysis
The observable behavior is consistent across both products:
- A DoQ client query is accepted on the frontend listener.
- The query is forwarded over a backend UDP leg.
- On that backend leg, the forwarded DNS
IDcollapses to0on the client-triggered path instead of remaining a fresh per-query variable. - The backend UDP source port is still allocated per query.
- When an ICMP error quotes the actual backend source port, the forwarding path flips behavior in a way that does not occur for a wrong quoted port.
That combination removes txid from the backend tuple on the tested path and
leaves the UDP source port as the main remaining variable. In practical terms,
the backend hop stops behaving like a fresh (txid, source-port) pair per
forwarded query and instead becomes a one-variable state exposure.
For dnsproxy, the correct quoted port does more than produce a failure signal:
it can push resolution away from the primary UDP upstream and into the fallback
upstream. For AdGuard Home, the same condition produces a fast SERVFAIL.
Reproduce
Prerequisites:
- Docker and Docker Compose
- OpenSSL
- build the lab helper image used by the attached harness and observer
The attached reproducer bundle contains only the files needed for this report:
- scripts:
attachments/scripts/ - helper image build files:
attachments/docker/unbound-doq-attacker/ - compose files:
attachments/docker-compose.g03.yml,attachments/docker-compose.g04.yml,attachments/docker-compose.g05.yml - shipped evidence:
attachments/artifacts/...
Build the helper image first:
cd attachmentsdocker build -t unbound-doq-attacker:latest -f docker/unbound-doq-attacker/Dockerfile docker/unbound-doq-attacker
To rerun dnsproxy:
cd attachmentsbash scripts/repro-g03-dnsproxy-oracle.sh- Inspect
artifacts/g03/<RUN_ID>/summary.txt - Inspect
artifacts/g03/<RUN_ID>/entropy-backend.jsonl,txid_correct-backend.jsonl, andport_correct-backend.jsonl
To rerun the dnsproxy fallback-steering case:
cd attachmentsbash scripts/repro-g04-dnsproxy-steering.sh- Inspect
artifacts/g04/<RUN_ID>/summary.txt - Inspect
steering_correct-main.jsonlandsteering_correct-fallback.jsonl
To rerun AdGuard Home:
cd attachmentsbash scripts/repro-g05-adguardhome-oracle.sh- Inspect
artifacts/g05/<RUN_ID>/summary.txt - Inspect
entropy-backend.jsonl,txid_correct-backend.jsonl, andport_correct-backend.jsonl
The attached evidence includes fresh dnsproxy v0.81.2 reruns, one official-
profile AdGuard Home run, and the minimal reproducer bundle used by both.
Impact
For both products, the tested DoQ-to-UDP path is no longer a full
(txid, source-port) search surface:
dnsproxy: four of four sampled runs showedtxid=0on the backend hop and a positive source-port oracle onv0.81.2. The remaining unknown isport_only. Median wrong/correct port latency was327.99 ms / 40.93 ms.AdGuard Home: four of four sampled runs showedtxid=0on the backend hop and a positive source-port oracle. The aggregate again classifies the remaining unknown asport_only. Median wrong/correct port latency was319.14 ms / 37.02 ms.
Product-specific effects:
dnsproxy: a correct port guess produced an empty client-visible answer on the base oracle path, and in the fallback profile it steered all eight tested queries away from the main upstream and into the fallback upstream.AdGuard Home: a correct port guess produced fastSERVFAILand an extra backend query.
This is the security-relevant point. On the tested official profiles, the
backend hop no longer forces an off-path attacker to deal with two fresh random
fields per forwarded DNS race. The DNS ID is already known: it is
deterministically 0 on the client-triggered DoQ-to-UDP path. The only
remaining backend tuple variable is the UDP source port, and the attached
evidence shows a repeatable oracle for that remaining variable.
That places the path in the same threat-model class as oracle-assisted DNS
forgery work such as SAD DNS and TUdoor: the attack first uses an oracle to
learn or validate the tuple state that protects an off-path response race, and
only then attempts the forged response. This report stops short of a forgery
demo, but the evidence already shows the crucial precondition on the tested
backend hop: the tuple is not high-entropy anymore. It has been reduced from
(txid, source-port) to source-port only.
Attachments attachments.zip
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.107.74"
},
"package": {
"ecosystem": "Go",
"name": "github.com/AdguardTeam/AdGuardHome"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.107.75"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/AdguardTeam/dnsproxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.81.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47703"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-662"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-04T19:50:23Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThis report covers the client-triggered DoQ forwarding path in:\n\n- `dnsproxy` `v0.81.2` (`adguard/dnsproxy:v0.81.2`)\n- `AdGuard Home` `v0.107.74` (`adguard/adguardhome:latest`, image version label `v0.107.74`)\n\nThe issue was reproduced on `2026-04-25` with the products configured through\ntheir documented DoQ listener and plain UDP upstream surfaces. The scope is the\ninternal backend UDP hop created when a DoQ query is forwarded to a `udp://`\nupstream.\n\nOn that path, the backend DNS `ID` is not preserved as an independent source of\nentropy. For both products, the backend observer saw `dns_id=0` for every\nsampled client-triggered query on the tested path. Repeated reruns then showed\nthe same `txid=0` behavior and the same positive source-port oracle on every\nsampled run. A separate quoted-port ICMP oracle distinguished the correct\nbackend UDP source port from a wrong one with a stable, client-visible behavior\nchange.\n\nAttached evidence:\n\n- `dnsproxy` oracle path on `v0.81.2`: [attachments/artifacts/g03/20260425T141500Z-g03-v0812/summary.txt](attachments/artifacts/g03/20260425T141500Z-g03-v0812/summary.txt)\n- `dnsproxy` `v0.81.2` repeatability: [attachments/artifacts/g03/repeatability-v0812.md](attachments/artifacts/g03/repeatability-v0812.md)\n- `dnsproxy` steering follow-up on `v0.81.2`: [attachments/artifacts/g04/20260425T141900Z-g04-v0812/summary.txt](attachments/artifacts/g04/20260425T141900Z-g04-v0812/summary.txt)\n- `AdGuard Home` oracle path: [attachments/artifacts/g05/20260425T113000Z-g05/summary.txt](attachments/artifacts/g05/20260425T113000Z-g05/summary.txt)\n\n## Root Cause Analysis\n\nThe observable behavior is consistent across both products:\n\n1. A DoQ client query is accepted on the frontend listener.\n2. The query is forwarded over a backend UDP leg.\n3. On that backend leg, the forwarded DNS `ID` collapses to `0` on the\n client-triggered path instead of remaining a fresh per-query variable.\n4. The backend UDP source port is still allocated per query.\n5. When an ICMP error quotes the actual backend source port, the forwarding path\n flips behavior in a way that does not occur for a wrong quoted port.\n\nThat combination removes `txid` from the backend tuple on the tested path and\nleaves the UDP source port as the main remaining variable. In practical terms,\nthe backend hop stops behaving like a fresh `(txid, source-port)` pair per\nforwarded query and instead becomes a one-variable state exposure.\n\nFor `dnsproxy`, the correct quoted port does more than produce a failure signal:\nit can push resolution away from the primary UDP upstream and into the fallback\nupstream. For `AdGuard Home`, the same condition produces a fast `SERVFAIL`.\n\n## Reproduce\n\nPrerequisites:\n\n- Docker and Docker Compose\n- OpenSSL\n- build the lab helper image used by the attached harness and observer\n\nThe attached reproducer bundle contains only the files needed for this report:\n\n- scripts: `attachments/scripts/`\n- helper image build files: `attachments/docker/unbound-doq-attacker/`\n- compose files: `attachments/docker-compose.g03.yml`,\n `attachments/docker-compose.g04.yml`, `attachments/docker-compose.g05.yml`\n- shipped evidence: `attachments/artifacts/...`\n\nBuild the helper image first:\n\n1. `cd attachments`\n2. `docker build -t unbound-doq-attacker:latest -f docker/unbound-doq-attacker/Dockerfile docker/unbound-doq-attacker`\n\nTo rerun `dnsproxy`:\n\n1. `cd attachments`\n2. `bash scripts/repro-g03-dnsproxy-oracle.sh`\n3. Inspect `artifacts/g03/\u003cRUN_ID\u003e/summary.txt`\n4. Inspect `artifacts/g03/\u003cRUN_ID\u003e/entropy-backend.jsonl`,\n `txid_correct-backend.jsonl`, and `port_correct-backend.jsonl`\n\nTo rerun the `dnsproxy` fallback-steering case:\n\n1. `cd attachments`\n2. `bash scripts/repro-g04-dnsproxy-steering.sh`\n3. Inspect `artifacts/g04/\u003cRUN_ID\u003e/summary.txt`\n4. Inspect `steering_correct-main.jsonl` and `steering_correct-fallback.jsonl`\n\nTo rerun `AdGuard Home`:\n\n1. `cd attachments`\n2. `bash scripts/repro-g05-adguardhome-oracle.sh`\n3. Inspect `artifacts/g05/\u003cRUN_ID\u003e/summary.txt`\n4. Inspect `entropy-backend.jsonl`, `txid_correct-backend.jsonl`, and\n `port_correct-backend.jsonl`\n\nThe attached evidence includes fresh `dnsproxy v0.81.2` reruns, one official-\nprofile `AdGuard Home` run, and the minimal reproducer bundle used by both.\n\n## Impact\n\nFor both products, the tested DoQ-to-UDP path is no longer a full\n`(txid, source-port)` search surface:\n\n- `dnsproxy`: four of four sampled runs showed `txid=0` on the backend hop and\n a positive source-port oracle on `v0.81.2`. The remaining unknown is\n `port_only`. Median wrong/correct port latency was `327.99 ms / 40.93 ms`.\n- `AdGuard Home`: four of four sampled runs showed `txid=0` on the backend hop\n and a positive source-port oracle. The aggregate again classifies the\n remaining unknown as `port_only`. Median wrong/correct port latency was\n `319.14 ms / 37.02 ms`.\n\nProduct-specific effects:\n\n- `dnsproxy`: a correct port guess produced an empty client-visible answer on\n the base oracle path, and in the fallback profile it steered all eight tested\n queries away from the main upstream and into the fallback upstream.\n- `AdGuard Home`: a correct port guess produced fast `SERVFAIL` and an extra\n backend query.\n\nThis is the security-relevant point. On the tested official profiles, the\nbackend hop no longer forces an off-path attacker to deal with two fresh random\nfields per forwarded DNS race. The DNS ID is already known: it is\ndeterministically `0` on the client-triggered DoQ-to-UDP path. The only\nremaining backend tuple variable is the UDP source port, and the attached\nevidence shows a repeatable oracle for that remaining variable.\n\nThat places the path in the same threat-model class as oracle-assisted DNS\nforgery work such as SAD DNS and TUdoor: the attack first uses an oracle to\nlearn or validate the tuple state that protects an off-path response race, and\nonly then attempts the forged response. This report stops short of a forgery\ndemo, but the evidence already shows the crucial precondition on the tested\nbackend hop: the tuple is not high-entropy anymore. It has been reduced from\n`(txid, source-port)` to `source-port` only.\n\n\n---\n\n**Attachments**\n[attachments.zip](https://github.com/user-attachments/files/27227054/attachments.zip)",
"id": "GHSA-xgx4-4h9w-53pv",
"modified": "2026-06-04T19:50:23Z",
"published": "2026-06-04T19:50:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/AdguardTeam/AdGuardHome/security/advisories/GHSA-xgx4-4h9w-53pv"
},
{
"type": "WEB",
"url": "https://github.com/AdguardTeam/dnsproxy/commit/f00d992ce9567a50f596853978ad6500acfdcf1d"
},
{
"type": "PACKAGE",
"url": "https://github.com/AdguardTeam/AdGuardHome"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "AdGuard Home: DoQ-to-UDP State Reduction and Source-Port Oracle"
}
GHSA-XH2C-5R7J-3G84
Vulnerability from github – Published: 2025-08-12 18:31 – Updated: 2025-08-12 18:31Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2025-49762"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-12T18:15:31Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-xh2c-5r7j-3g84",
"modified": "2025-08-12T18:31:30Z",
"published": "2025-08-12T18:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49762"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-49762"
}
],
"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"
}
]
}
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.