Total
539 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-39826 | 1 Zoom | 3 Meeting Software Development Kit, Workplace Desktop, Workplace Virtual Desktop Infrastructure | 2025-10-02 | 6.8 Medium |
| Race condition in Team Chat for some Zoom Workplace Apps and SDKs for Windows may allow an authenticated user to conduct information disclosure via network access. | ||||
| CVE-2024-42444 | 1 Ami | 1 Aptio V | 2025-10-02 | 7.5 High |
| APTIOV contains a vulnerability in BIOS where an attacker may cause a TOCTOU Race Condition by local means. Successful exploitation of this vulnerability may lead to execution of arbitrary code on the target device. | ||||
| CVE-2024-42446 | 1 Ami | 1 Aptio V | 2025-10-02 | 7.5 High |
| 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. | ||||
| CVE-2024-54084 | 1 Ami | 1 Aptio V | 2025-10-02 | 7.5 High |
| 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. | ||||
| CVE-2025-21998 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: uefisecapp: fix efivars registration race Since the conversion to using the TZ allocator, the efivars service is registered before the memory pool has been allocated, something which can lead to a NULL-pointer dereference in case of a racing EFI variable access. Make sure that all resources have been set up before registering the efivars. | ||||
| CVE-2024-36943 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix loss of young/dirty bits during pagemap scan make_uffd_wp_pte() was previously doing: pte = ptep_get(ptep); ptep_modify_prot_start(ptep); pte = pte_mkuffd_wp(pte); ptep_modify_prot_commit(ptep, pte); But if another thread accessed or dirtied the pte between the first 2 calls, this could lead to loss of that information. Since ptep_modify_prot_start() gets and clears atomically, the following is the correct pattern and prevents any possible race. Any access after the first call would see an invalid pte and cause a fault: pte = ptep_modify_prot_start(ptep); pte = pte_mkuffd_wp(pte); ptep_modify_prot_commit(ptep, pte); | ||||
| CVE-2024-47813 | 1 Bytecodealliance | 1 Wasmtime | 2025-09-29 | 2.9 Low |
| Wasmtime is an open source runtime for WebAssembly. Under certain concurrent event orderings, a `wasmtime::Engine`'s internal type registry was susceptible to double-unregistration bugs due to a race condition, leading to panics and potentially type registry corruption. That registry corruption could, following an additional and particular sequence of concurrent events, lead to violations of WebAssembly's control-flow integrity (CFI) and type safety. Users that do not use `wasmtime::Engine` across multiple threads are not affected. Users that only create new modules across threads over time are additionally not affected. Reproducing this bug requires creating and dropping multiple type instances (such as `wasmtime::FuncType` or `wasmtime::ArrayType`) concurrently on multiple threads, where all types are associated with the same `wasmtime::Engine`. **Wasm guests cannot trigger this bug.** See the "References" section below for a list of Wasmtime types-related APIs that are affected. Wasmtime maintains an internal registry of types within a `wasmtime::Engine` and an engine is shareable across threads. Types can be created and referenced through creation of a `wasmtime::Module`, creation of `wasmtime::FuncType`, or a number of other APIs where the host creates a function (see "References" below). Each of these cases interacts with an engine to deduplicate type information and manage type indices that are used to implement type checks in WebAssembly's `call_indirect` function, for example. This bug is a race condition in this management where the internal type registry could be corrupted to trigger an assert or contain invalid state. Wasmtime's internal representation of a type has individual types (e.g. one-per-host-function) maintain a registration count of how many time it's been used. Types additionally have state within an engine behind a read-write lock such as lookup/deduplication information. The race here is a time-of-check versus time-of-use (TOCTOU) bug where one thread atomically decrements a type entry's registration count, observes zero registrations, and then acquires a lock in order to unregister that entry. However, between when this first thread observed the zero-registration count and when it acquires that lock, another thread could perform the following sequence of events: re-register another copy of the type, which deduplicates to that same entry, resurrecting it and incrementing its registration count; then drop the type and decrement its registration count; observe that the registration count is now zero; acquire the type registry lock; and finally unregister the type. Now, when the original thread finally acquires the lock and unregisters the entry, it is the second time this entry has been unregistered. This bug was originally introduced in Wasmtime 19's development of the WebAssembly GC proposal. This bug affects users who are not using the GC proposal, however, and affects Wasmtime in its default configuration even when the GC proposal is disabled. Wasmtime users using 19.0.0 and after are all affected by this issue. We have released the following Wasmtime versions, all of which have a fix for this bug: * 21.0.2 * 22.0.1 * 23.0.3 * 24.0.1 * 25.0.2. If your application creates and drops Wasmtime types on multiple threads concurrently, there are no known workarounds. Users are encouraged to upgrade to a patched release. | ||||
| CVE-2024-50220 | 1 Linux | 1 Linux Kernel | 2025-09-26 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series "fork: do not expose incomplete mm on fork". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here. | ||||
| CVE-2023-3891 | 1 Lapce | 1 Lapce | 2025-09-25 | 7.3 High |
| Race condition in Lapce v0.2.8 allows an attacker to elevate privileges on the system | ||||
| CVE-2025-23359 | 2 Linux, Nvidia | 4 Linux Kernel, Container Toolkit, Nvidia Container Toolkit and 1 more | 2025-09-25 | 8.3 High |
| NVIDIA Container Toolkit for Linux contains a Time-of-Check Time-of-Use (TOCTOU) vulnerability when used with default configuration, where a crafted container image could gain access to the host file system. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. | ||||
| CVE-2025-47290 | 1 Linuxfoundation | 1 Containerd | 2025-09-19 | 5.9 Medium |
| containerd is a container runtime. A time-of-check to time-of-use (TOCTOU) vulnerability was found in containerd v2.1.0. While unpacking an image during an image pull, specially crafted container images could arbitrarily modify the host file system. The only affected version of containerd is 2.1.0. Other versions of containerd are not affected. This bug has been fixed in containerd 2.1.1. Users should update to this version to resolve the issue. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images. | ||||
| CVE-2024-36027 | 1 Linux | 1 Linux Kernel | 2025-09-18 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: do not flag ZEROOUT on non-dirty extent buffer Btrfs clears the content of an extent buffer marked as EXTENT_BUFFER_ZONED_ZEROOUT before the bio submission. This mechanism is introduced to prevent a write hole of an extent buffer, which is once allocated, marked dirty, but turns out unnecessary and cleaned up within one transaction operation. Currently, btrfs_clear_buffer_dirty() marks the extent buffer as EXTENT_BUFFER_ZONED_ZEROOUT, and skips the entry function. If this call happens while the buffer is under IO (with the WRITEBACK flag set, without the DIRTY flag), we can add the ZEROOUT flag and clear the buffer's content just before a bio submission. As a result: 1) it can lead to adding faulty delayed reference item which leads to a FS corrupted (EUCLEAN) error, and 2) it writes out cleared tree node on disk The former issue is previously discussed in [1]. The corruption happens when it runs a delayed reference update. So, on-disk data is safe. [1] https://lore.kernel.org/linux-btrfs/3f4f2a0ff1a6c818050434288925bdcf3cd719e5.1709124777.git.naohiro.aota@wdc.com/ The latter one can reach on-disk data. But, as that node is already processed by btrfs_clear_buffer_dirty(), that will be invalidated in the next transaction commit anyway. So, the chance of hitting the corruption is relatively small. Anyway, we should skip flagging ZEROOUT on a non-DIRTY extent buffer, to keep the content under IO intact. | ||||
| CVE-2025-58131 | 2 Apple, Zoom | 4 Macos, Vdi Vmware, Workplace and 1 more | 2025-09-12 | 6.6 Medium |
| Race condition in the Zoom Workplace VDI Plugin macOS Universal installer for VMware Horizon before version 6.4.10 (or before 6.2.15 and 6.3.12 in their respective tracks) may allow an authenticated user to conduct a disclosure of information via network access. | ||||
| CVE-2025-29833 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-09-10 | 7.7 High |
| Time-of-check time-of-use (toctou) race condition in Windows Virtual Machine Bus allows an unauthorized attacker to execute code locally. | ||||
| CVE-2025-29969 | 1 Microsoft | 15 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 12 more | 2025-09-10 | 7.5 High |
| Time-of-check time-of-use (toctou) race condition in Windows Fundamentals allows an authorized attacker to execute code over a network. | ||||
| CVE-2024-10972 | 2025-09-05 | 7.3 High | ||
| Velocidex WinPmem versions 4.1 and below suffer from an Improper Input Validation vulnerability whereby an attacker with admin access can trigger a BSOD with a parallel thread changing the memory’s access right under the control of the user-mode application. This is due to verification only being performed at the beginning of the routine allowing the userspace to change page permissions half way through the routine. A valid workaround is a rule to detect unauthorized loading of winpmem outside incident response operations. | ||||
| CVE-2024-2440 | 1 Github | 1 Enterprise Server | 2025-09-02 | 5.5 Medium |
| A race condition in GitHub Enterprise Server allowed an existing admin to maintain permissions on a detached repository by making a GraphQL mutation to alter repository permissions while the repository is detached. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.13 and was fixed in versions 3.9.13, 3.10.10, 3.11.8 and 3.12.1. This vulnerability was reported via the GitHub Bug Bounty program. | ||||
| CVE-2025-9810 | 1 Linenoise Project | 1 Linenoise | 2025-09-02 | 6.8 Medium |
| TOCTOU in linenoiseHistorySave in linenoise allows local attackers to overwrite arbitrary files and change permissions via a symlink race between fopen("w") on the history path and subsequent chmod() on the same path. | ||||
| CVE-2025-44002 | 2 Microsoft, Teamviewer | 3 Windows, Full Client, Host | 2025-08-27 | 6.1 Medium |
| Race Condition in the Directory Validation Logic in the TeamViewer Full Client and Host prior version 15.69 on Windows allows a local non-admin user to create arbitrary files with SYSTEM privileges, potentially leading to a denial-of-service condition, via symbolic link manipulation during directory verification. | ||||
| CVE-2021-3899 | 1 Canonical | 2 Apport, Ubuntu Linux | 2025-08-26 | 7.8 High |
| There is a race condition in the 'replaced executable' detection that, with the correct local configuration, allow an attacker to execute arbitrary code as root. | ||||