Common Weakness Enumeration

CWE-367

Allowed

Time-of-check Time-of-use (TOCTOU) Race Condition

Abstraction: Base · Status: Incomplete

The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.

1286 vulnerabilities reference this CWE, most recent first.

GHSA-4MP8-C9W5-FF64

Vulnerability from github – Published: 2025-07-03 09:30 – Updated: 2025-12-17 18:31
VLAI
Details

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

net: Fix TOCTOU issue in sk_is_readable()

sk->sk_prot->sock_is_readable is a valid function pointer when sk resides in a sockmap. After the last sk_psock_put() (which usually happens when socket is removed from sockmap), sk->sk_prot gets restored and sk->sk_prot->sock_is_readable becomes NULL.

This makes sk_is_readable() racy, if the value of sk->sk_prot is reloaded after the initial check. Which in turn may lead to a null pointer dereference.

Ensure the function pointer does not turn NULL after the check.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-38112"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-03T09:15:24Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: Fix TOCTOU issue in sk_is_readable()\n\nsk-\u003esk_prot-\u003esock_is_readable is a valid function pointer when sk resides\nin a sockmap. After the last sk_psock_put() (which usually happens when\nsocket is removed from sockmap), sk-\u003esk_prot gets restored and\nsk-\u003esk_prot-\u003esock_is_readable becomes NULL.\n\nThis makes sk_is_readable() racy, if the value of sk-\u003esk_prot is reloaded\nafter the initial check. Which in turn may lead to a null pointer\ndereference.\n\nEnsure the function pointer does not turn NULL after the check.",
  "id": "GHSA-4mp8-c9w5-ff64",
  "modified": "2025-12-17T18:31:31Z",
  "published": "2025-07-03T09:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38112"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1b367ba2f94251822577daed031d6b9a9e11ba91"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1e0de7582ceccbdbb227d4e0ddf65732f92526da"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2660a544fdc0940bba15f70508a46cf9a6491230"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6fa68d7eab34d448a61aa24ea31e68b3231ed20d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8926a7ef1977a832dd6bf702f1a99303dbf15b15"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c2b26638476baee154920bb587fc94ff1bf04336"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ff55c85a923e043d59d26b20a673a1b4a219c310"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-4MW4-QWHG-37XG

Vulnerability from github – Published: 2026-03-11 00:31 – Updated: 2026-03-11 00:31
VLAI
Details

Time-of-check time-of-use race condition in the WheaERST SMM module for some Intel(R) reference platforms may allow an escalation of privilege. System software adversary with a privileged user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-20028"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-10T23:16:41Z",
    "severity": "HIGH"
  },
  "details": "Time-of-check time-of-use race condition in the WheaERST SMM module for some Intel(R) reference platforms may allow an escalation of privilege. System software adversary with a privileged user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.",
  "id": "GHSA-4mw4-qwhg-37xg",
  "modified": "2026-03-11T00:31:35Z",
  "published": "2026-03-11T00:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20028"
    },
    {
      "type": "WEB",
      "url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01234.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/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-4P53-C8JQ-G93H

Vulnerability from github – Published: 2023-01-11 09:30 – Updated: 2023-01-24 18:30
VLAI
Details

TOCTOU in the ASP may allow a physical attacker to write beyond the buffer bounds, potentially leading to a loss of integrity or denial of service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-20523"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-11T08:15:00Z",
    "severity": "MODERATE"
  },
  "details": "TOCTOU in the ASP may allow a physical attacker to write beyond the buffer bounds, potentially leading to a loss of integrity or denial of service.",
  "id": "GHSA-4p53-c8jq-g93h",
  "modified": "2023-01-24T18:30:33Z",
  "published": "2023-01-11T09:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20523"
    },
    {
      "type": "WEB",
      "url": "https://www.amd.com/en/corporate/product-security/bulletin/AMD-SB-1032"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4P6C-XJ99-MXP8

Vulnerability from github – Published: 2026-07-01 18:31 – Updated: 2026-07-01 18:31
VLAI
Details

NVIDIA Container Toolkit for Linux contains a vulnerability where an attacker could cause a time-of-check time-of-use race condition. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, and data tampering.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-24260"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-01T16:16:45Z",
    "severity": "HIGH"
  },
  "details": "NVIDIA Container Toolkit for Linux contains a vulnerability where an attacker could cause a time-of-check time-of-use race condition. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, and data tampering.",
  "id": "GHSA-4p6c-xj99-mxp8",
  "modified": "2026-07-01T18:31:49Z",
  "published": "2026-07-01T18:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24260"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NVIDIA/product-security/tree/main/2026/5850"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-24260"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4PRC-VPWG-W736

Vulnerability from github – Published: 2025-03-11 15:30 – Updated: 2025-03-11 15:30
VLAI
Details

APTIOV contains a vulnerability in BIOS where an attacker may cause a Time-of-check Time-of-use (TOCTOU) Race Condition by local means. Successful exploitation of this vulnerability may lead to arbitrary code execution.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-54084"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-11T14:15:22Z",
    "severity": "HIGH"
  },
  "details": "APTIOV contains a vulnerability in BIOS where an attacker may cause a Time-of-check Time-of-use (TOCTOU) Race Condition by local means. Successful exploitation of this vulnerability may lead to arbitrary code execution.",
  "id": "GHSA-4prc-vpwg-w736",
  "modified": "2025-03-11T15:30:59Z",
  "published": "2025-03-11T15:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54084"
    },
    {
      "type": "WEB",
      "url": "https://go.ami.com/hubfs/Security%20Advisories/2025/AMI-SA-2025003.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4QR2-3MPC-GRQM

Vulnerability from github – Published: 2026-08-06 12:31 – Updated: 2026-08-07 00:31
VLAI
Details

A race condition in JCacheCodeDataProvider allows an attacker to redeem a single authorization code multiple times via concurrent requests, resulting in the issuance of multiple distinct, valid access tokens. Users are recommended to upgrade to versions 4.2.3, 4.1.8 or 3.6.12, which fix this issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-57818"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-06T12:16:27Z",
    "severity": "HIGH"
  },
  "details": "A race condition in JCacheCodeDataProvider allows an attacker to redeem a single authorization code multiple times via concurrent requests, resulting in the issuance of multiple distinct, valid access tokens. Users are recommended to upgrade to versions 4.2.3, 4.1.8 or 3.6.12, which fix this issue.",
  "id": "GHSA-4qr2-3mpc-grqm",
  "modified": "2026-08-07T00:31:10Z",
  "published": "2026-08-06T12:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57818"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/7q08mz8bcbosp25wok7gr537zlp15mfz"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/08/06/20"
    }
  ],
  "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-4RRH-WMGW-CHC3

Vulnerability from github – Published: 2023-02-15 03:30 – Updated: 2023-02-23 18:31
VLAI
Details

An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the IdeBusDxe shared buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the firmware block services data to SMRAM before checking it.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-32478"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-15T02:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the IdeBusDxe shared buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the firmware block services data to SMRAM before checking it.",
  "id": "GHSA-4rrh-wmgw-chc3",
  "modified": "2023-02-23T18:31:05Z",
  "published": "2023-02-15T03:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32478"
    },
    {
      "type": "WEB",
      "url": "https://www.insyde.com/security-pledge"
    },
    {
      "type": "WEB",
      "url": "https://www.insyde.com/security-pledge/SA-2023010"
    }
  ],
  "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-4V28-J6Q3-5M4R

Vulnerability from github – Published: 2026-09-10 15:10 – Updated: 2026-09-10 15:10
VLAI
Summary
Open WebUI: SSRF into internal services via DNS rebinding in the Playwright web loader
Details

Summary

With the Playwright web loader enabled, Open WebUI checks the address behind a user-submitted URL before allowing the request, then handed the request to the browser to perform. The browser resolved the hostname a second time, on its own, and that answer was never checked. An attacker who controls the authoritative DNS for a hostname they submit can answer the first lookup with a public address and the second with an internal one, so the browser connects to an address the check exists to block. The connection-layer pinning that protects the other fetch paths could not apply here, because the request ran inside the browser rather than through our own HTTP clients.

Preconditions

  • WEB_LOADER_ENGINE=playwright. This is not the default, and deployments on the default web loader are unaffected.
  • A reachable Playwright browser, either local or via PLAYWRIGHT_WS_URL.
  • Any authenticated user who can submit a URL for ingestion or trigger a web search. No administrator role is required.
  • Control of the authoritative DNS for a hostname the attacker submits, serving a short TTL and alternating answers. No timing race is needed, because the two lookups are separate queries the attacker answers differently.
  • Internal services the browser process can actually reach. A deployment whose browser has no route to internal addresses loses nothing here.

Impact

An authenticated user can make the server read HTTP responses from addresses only it can reach: cloud instance metadata, loopback-bound admin APIs, and internal services on the same network. The response body is fulfilled back into the page, and the loader returns that page as the document, so the content lands in the web-search or ingestion result the user receives. On a cloud host with IMDSv1 reachable, that is enough to take instance IAM credentials.

Because the intercepted request forwards the original method and headers, a page the attacker controls can also drive requests that need a header or a non-GET method, which covers the header-gated metadata endpoints. This is a read primitive; no modification of Open WebUI data and no availability impact was demonstrated. Deployments on the default web loader are not affected at all.

Fix

Fixed in 0.11.1 by commit 27402ff21 (#28634). The interceptor no longer asks the browser to perform the request. It issues the request from the SSRF-safe HTTP client instead, which resolves the hostname once and connects to that same validated address, re-validates every redirect hop, and then fulfils the browser with the response it received. Upgrading to 0.11.1 fully resolves this, and no configuration change is required.

Root cause

Affected component: SafePlaywrightURLLoader in backend/open_webui/retrieval/web/utils.py, in both the sync and async request interceptors. Affected setup: only builds running the Playwright loader engine.

The address check and the connection were performed by two different resolvers in two different processes. Validation resolved the hostname in Python and inspected the result, then the request was handed to the browser, which resolved the name again and connected to whatever it got. Playwright's request-fetch API offers no way to pin a connection to an already-validated address, so the fix that had been applied to the other fetch paths, resolving once and connecting to that same address, could not reach this one. The check was therefore an opinion about an earlier lookup rather than a constraint on the connection that followed.

Proof of concept

Reproduced against the real implementation: the validation and interception code was taken unmodified, with only the module-level configuration constants stubbed at their documented defaults, and driven against a real Chromium instance inside an unprivileged network namespace with an authoritative DNS server answering the first lookup public and the second internal. Instance metadata and a loopback service were both reached, with the response body returned through the page. A second run showed an attacker-controlled page driving the header-gated metadata sequence to completion. The path from the HTTP endpoint to the loader was traced in source rather than driven end to end.

Credits

  • @baeseungwon1010 — identified that the address check and the browser's own resolution are two separate lookups, so the check cannot constrain where the browser connects.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.6"
            },
            {
              "fixed": "0.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-87996"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-10T15:10:12Z",
    "nvd_published_at": "2026-09-09T22:18:47Z",
    "severity": "HIGH"
  },
  "details": "## Summary\nWith the Playwright web loader enabled, Open WebUI checks the address behind a user-submitted URL before allowing the request, then handed the request to the browser to perform. The browser resolved the hostname a second time, on its own, and that answer was never checked. An attacker who controls the authoritative DNS for a hostname they submit can answer the first lookup with a public address and the second with an internal one, so the browser connects to an address the check exists to block. The connection-layer pinning that protects the other fetch paths could not apply here, because the request ran inside the browser rather than through our own HTTP clients.\n\n## Preconditions\n- `WEB_LOADER_ENGINE=playwright`. This is not the default, and deployments on the default web loader are unaffected.\n- A reachable Playwright browser, either local or via `PLAYWRIGHT_WS_URL`.\n- Any authenticated user who can submit a URL for ingestion or trigger a web search. No administrator role is required.\n- Control of the authoritative DNS for a hostname the attacker submits, serving a short TTL and alternating answers. No timing race is needed, because the two lookups are separate queries the attacker answers differently.\n- Internal services the browser process can actually reach. A deployment whose browser has no route to internal addresses loses nothing here.\n\n## Impact\nAn authenticated user can make the server read HTTP responses from addresses only it can reach: cloud instance metadata, loopback-bound admin APIs, and internal services on the same network. The response body is fulfilled back into the page, and the loader returns that page as the document, so the content lands in the web-search or ingestion result the user receives. On a cloud host with IMDSv1 reachable, that is enough to take instance IAM credentials.\n\nBecause the intercepted request forwards the original method and headers, a page the attacker controls can also drive requests that need a header or a non-GET method, which covers the header-gated metadata endpoints. This is a read primitive; no modification of Open WebUI data and no availability impact was demonstrated. Deployments on the default web loader are not affected at all.\n\n## Fix\nFixed in 0.11.1 by commit `27402ff21` (#28634). The interceptor no longer asks the browser to perform the request. It issues the request from the SSRF-safe HTTP client instead, which resolves the hostname once and connects to that same validated address, re-validates every redirect hop, and then fulfils the browser with the response it received. Upgrading to 0.11.1 fully resolves this, and no configuration change is required.\n\n## Root cause\nAffected component: `SafePlaywrightURLLoader` in `backend/open_webui/retrieval/web/utils.py`, in both the sync and async request interceptors. Affected setup: only builds running the Playwright loader engine.\n\nThe address check and the connection were performed by two different resolvers in two different processes. Validation resolved the hostname in Python and inspected the result, then the request was handed to the browser, which resolved the name again and connected to whatever it got. Playwright\u0027s request-fetch API offers no way to pin a connection to an already-validated address, so the fix that had been applied to the other fetch paths, resolving once and connecting to that same address, could not reach this one. The check was therefore an opinion about an earlier lookup rather than a constraint on the connection that followed.\n\n## Proof of concept\nReproduced against the real implementation: the validation and interception code was taken unmodified, with only the module-level configuration constants stubbed at their documented defaults, and driven against a real Chromium instance inside an unprivileged network namespace with an authoritative DNS server answering the first lookup public and the second internal. Instance metadata and a loopback service were both reached, with the response body returned through the page. A second run showed an attacker-controlled page driving the header-gated metadata sequence to completion. The path from the HTTP endpoint to the loader was traced in source rather than driven end to end.\n\n## Credits\n- **@baeseungwon1010** \u2014 identified that the address check and the browser\u0027s own resolution are two separate lookups, so the check cannot constrain where the browser connects.",
  "id": "GHSA-4v28-j6q3-5m4r",
  "modified": "2026-09-10T15:10:12Z",
  "published": "2026-09-10T15:10:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-4v28-j6q3-5m4r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87996"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/pull/28634"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/27402ff210bfa253445720920dfb86b15a00327b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: SSRF into internal services via DNS rebinding in the Playwright web loader"
}

GHSA-4VPV-7RCQ-X7HW

Vulnerability from github – Published: 2023-05-17 00:30 – Updated: 2024-04-04 04:12
VLAI
Details

Videostream macOS app 0.5.0 and 0.4.3 has a Race Condition. The Updater privileged script attempts to update Videostream every 5 hours.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-25394"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-17T00:15:08Z",
    "severity": "HIGH"
  },
  "details": "Videostream macOS app 0.5.0 and 0.4.3 has a Race Condition. The Updater privileged script attempts to update Videostream every 5 hours.",
  "id": "GHSA-4vpv-7rcq-x7hw",
  "modified": "2024-04-04T04:12:32Z",
  "published": "2023-05-17T00:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25394"
    },
    {
      "type": "WEB",
      "url": "https://danrevah.github.io/2023/05/03/CVE-2023-25394-VideoStream-LPE"
    },
    {
      "type": "WEB",
      "url": "https://getvideostream.com"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/757109"
    }
  ],
  "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-4W64-3HFC-PGQC

Vulnerability from github – Published: 2026-04-24 15:32 – Updated: 2026-04-28 21:36
VLAI
Details

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

smb: client: make use of smbdirect_socket.recv_io.credits.available

The logic off managing recv credits by counting posted recv_io and granted credits is racy.

That's because the peer might already consumed a credit, but between receiving the incoming recv at the hardware and processing the completion in the 'recv_done' functions we likely have a window where we grant credits, which don't really exist.

So we better have a decicated counter for the available credits, which will be incremented when we posted new recv buffers and drained when we grant the credits to the peer.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-31535"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-24T15:16:27Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: make use of smbdirect_socket.recv_io.credits.available\n\nThe logic off managing recv credits by counting posted recv_io and\ngranted credits is racy.\n\nThat\u0027s because the peer might already consumed a credit,\nbut between receiving the incoming recv at the hardware\nand processing the completion in the \u0027recv_done\u0027 functions\nwe likely have a window where we grant credits, which\ndon\u0027t really exist.\n\nSo we better have a decicated counter for the\navailable credits, which will be incremented\nwhen we posted new recv buffers and drained when\nwe grant the credits to the peer.",
  "id": "GHSA-4w64-3hfc-pgqc",
  "modified": "2026-04-28T21:36:01Z",
  "published": "2026-04-24T15:32:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31535"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9911b1ed187a770a43950bf51f340ad4b7beecba"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/be8845ad5d6558703d20567d8702155598325db8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f664e6e8a81103cb45c8802a9bc7499e0902c458"
    }
  ],
  "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"
    }
  ]
}

Mitigation
Implementation

The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.

Mitigation
Implementation

When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.

Mitigation
Architecture and Design

Limit the interleaving of operations on files from multiple processes.

Mitigation
Implementation Architecture and Design

If you cannot perform operations atomically and you must share access to the resource between multiple processes or threads, then try to limit the amount of time (CPU cycles) between the check and use of the resource. This will not fix the problem, but it could make it more difficult for an attack to succeed.

Mitigation
Implementation

Recheck the resource after the use call to verify that the action was taken appropriately.

Mitigation
Architecture and Design

Ensure that some environmental locking mechanism can be used to protect resources effectively.

Mitigation
Implementation

Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use.

CAPEC-27: Leveraging Race Conditions via Symbolic Links

This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary 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.