Common Weakness Enumeration

CWE-362

Allowed-with-Review

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Abstraction: Class · Status: Draft

API response cwe.mitre.org

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.

2896 vulnerabilities reference this CWE, most recent first.

GHSA-XF8V-VF86-4582

Vulnerability from github – Published: 2022-05-17 00:50 – Updated: 2022-05-17 00:50
VLAI
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".

Severity
8.1 (High)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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:30
VLAI
Details

In 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---

Severity
4.7 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "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:00
VLAI
Details

A 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.

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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:32
VLAI
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.

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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:30
VLAI
Details

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally.

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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:50
VLAI
Summary
AdGuard Home: DoQ-to-UDP State Reduction and Source-Port Oracle
Details

Summary

This report covers the client-triggered DoQ forwarding path in:

  • dnsproxy v0.81.2 (adguard/dnsproxy:v0.81.2)
  • AdGuard Home v0.107.74 (adguard/adguardhome:latest, image version label v0.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:

Root Cause Analysis

The observable behavior is consistent across both products:

  1. A DoQ client query is accepted on the frontend listener.
  2. The query is forwarded over a backend UDP leg.
  3. On that backend leg, the forwarded DNS ID collapses to 0 on the client-triggered path instead of remaining a fresh per-query variable.
  4. The backend UDP source port is still allocated per query.
  5. 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:

  1. cd attachments
  2. docker build -t unbound-doq-attacker:latest -f docker/unbound-doq-attacker/Dockerfile docker/unbound-doq-attacker

To rerun dnsproxy:

  1. cd attachments
  2. bash scripts/repro-g03-dnsproxy-oracle.sh
  3. Inspect artifacts/g03/<RUN_ID>/summary.txt
  4. Inspect artifacts/g03/<RUN_ID>/entropy-backend.jsonl, txid_correct-backend.jsonl, and port_correct-backend.jsonl

To rerun the dnsproxy fallback-steering case:

  1. cd attachments
  2. bash scripts/repro-g04-dnsproxy-steering.sh
  3. Inspect artifacts/g04/<RUN_ID>/summary.txt
  4. Inspect steering_correct-main.jsonl and steering_correct-fallback.jsonl

To rerun AdGuard Home:

  1. cd attachments
  2. bash scripts/repro-g05-adguardhome-oracle.sh
  3. Inspect artifacts/g05/<RUN_ID>/summary.txt
  4. Inspect entropy-backend.jsonl, txid_correct-backend.jsonl, and port_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 showed txid=0 on the backend hop and a positive source-port oracle on v0.81.2. The remaining unknown is port_only. Median wrong/correct port latency was 327.99 ms / 40.93 ms.
  • AdGuard Home: four of four sampled runs showed txid=0 on the backend hop and a positive source-port oracle. The aggregate again classifies the remaining unknown as port_only. Median wrong/correct port latency was 319.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 fast SERVFAIL and 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

Severity
6.9 (Medium)
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
Show details on source website
To clipboard 

{
  "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:31
VLAI
Details

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally.

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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"
    }
  ]
}

GHSA-XH2X-3MRM-FWQM

Vulnerability from github – Published: 2024-10-10 22:04 – Updated: 2025-01-21 17:18
VLAI
Summary
Gradio has a race condition in update_root_in_config may redirect user traffic
Details

Impact

What kind of vulnerability is it? Who is impacted?

This vulnerability involves a race condition in the update_root_in_config function, allowing an attacker to modify the root URL used by the Gradio frontend to communicate with the backend. By exploiting this flaw, an attacker can redirect user traffic to a malicious server. This could lead to the interception of sensitive data such as authentication credentials or uploaded files. This impacts all users who connect to a Gradio server, especially those exposed to the internet, where malicious actors could exploit this race condition.

Patches

Yes, please upgrade to gradio>=5 to address this issue.

Severity
7.0 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H
8.8 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "gradio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47870"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-10T22:04:21Z",
    "nvd_published_at": "2024-10-10T23:15:03Z",
    "severity": "HIGH"
  },
  "details": "### Impact  \n**What kind of vulnerability is it? Who is impacted?**\n\nThis vulnerability involves a **race condition** in the `update_root_in_config` function, allowing an attacker to modify the `root` URL used by the Gradio frontend to communicate with the backend. By exploiting this flaw, an attacker can redirect user traffic to a malicious server. This could lead to the interception of sensitive data such as authentication credentials or uploaded files. This impacts all users who connect to a Gradio server, especially those exposed to the internet, where malicious actors could exploit this race condition.\n\n### Patches  \nYes, please upgrade to `gradio\u003e=5` to address this issue.",
  "id": "GHSA-xh2x-3mrm-fwqm",
  "modified": "2025-01-21T17:18:30Z",
  "published": "2024-10-10T22:04:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gradio-app/gradio/security/advisories/GHSA-xh2x-3mrm-fwqm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47870"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gradio-app/gradio"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/gradio/PYSEC-2024-218.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gradio has a race condition in update_root_in_config may redirect user traffic"
}

GHSA-XH36-8Q3W-G243

Vulnerability from github – Published: 2024-01-21 12:30 – Updated: 2025-11-04 21:31
VLAI
Details

A use-after-free flaw was found in the Linux Kernel due to a race problem in the unix garbage collector's deletion of SKB races with unix_stream_read_generic() on the socket that the SKB is queued on.

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-6531"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-21T10:15:07Z",
    "severity": "HIGH"
  },
  "details": "A use-after-free flaw was found in the Linux Kernel due to a race problem in the unix garbage collector\u0027s deletion of SKB races with unix_stream_read_generic() on the socket that the SKB is queued on.",
  "id": "GHSA-xh36-8q3w-g243",
  "modified": "2025-11-04T21:31:04Z",
  "published": "2024-01-21T12:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6531"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:2394"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-6531"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2253034"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"
    },
    {
      "type": "WEB",
      "url": "https://lore.kernel.org/all/c716c88321939156909cfa1bd8b0faaf1c804103.1701868795.git.asml.silence@gmail.com"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/176533/Linux-Broken-Unix-GC-Interaction-Use-After-Free.html"
    }
  ],
  "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-XH92-7747-9M8G

Vulnerability from github – Published: 2022-10-12 12:00 – Updated: 2025-01-03 00:31
VLAI
Details

Windows Storage Elevation of Privilege Vulnerability.

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-38027"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-11T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Windows Storage Elevation of Privilege Vulnerability.",
  "id": "GHSA-xh92-7747-9m8g",
  "modified": "2025-01-03T00:31:07Z",
  "published": "2022-10-12T12:00:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38027"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-38027"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-38027"
    }
  ],
  "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
Architecture and Design

In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.

Mitigation
Architecture and Design

Use thread-safe capabilities such as the data access abstraction in Spring.

Mitigation
Architecture and Design
  • 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
Implementation

When using multithreading and operating on shared variables, only use thread-safe functions.

Mitigation
Implementation

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
Implementation

Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.

Mitigation
Implementation

Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.

Mitigation
Implementation

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
Implementation

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
Architecture and Design Operation

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.

← Back to the CWE list