Total
2978 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2022-3303 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-10-14 | N/A | 4.7 MEDIUM |
| A race condition flaw was found in the Linux kernel sound subsystem due to improper locking. It could lead to a NULL pointer dereference while handling the SNDCTL_DSP_SYNC ioctl. A privileged local user (root or member of the audio group) could use this flaw to crash the system, resulting in a denial of service condition | |||||
| CVE-2022-3028 | 3 Debian, Fedoraproject, Linux | 3 Debian Linux, Fedora, Linux Kernel | 2026-10-14 | N/A | 7.0 HIGH |
| A race condition was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem) when multiple calls to xfrm_probe_algs occurred simultaneously. This flaw could allow a local attacker to potentially trigger an out-of-bounds write or leak kernel heap memory by performing an out-of-bounds read and copying it into a socket. | |||||
| CVE-2022-2959 | 1 Linux | 1 Linux Kernel | 2026-10-14 | N/A | 7.0 HIGH |
| 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. | |||||
| CVE-2026-94583 | 1 Broadcom | 1 Fabric Operating System | 2026-10-14 | N/A | 2.6 LOW |
| A race condition vulnerability exists in the request processing logic of the REST management interface on Brocade Fabric OS versions before 10.0.1. When handling concurrent incoming network management FCIP requests, a timing window exists between when a request populates the address variable and when the service constructs and returns the response context. As a result, the first request adopts the modified context, causing the service to return sensitive management details or configuration data belonging to the second context back to the original requester. | |||||
| CVE-2022-1462 | 3 Debian, Linux, Redhat | 3 Debian Linux, Linux Kernel, Enterprise Linux | 2026-10-14 | 3.3 LOW | 6.3 MEDIUM |
| An out-of-bounds read flaw was found in the Linux kernel’s TeleTYpe subsystem. The issue occurs in how a user triggers a race condition using ioctls TIOCSPTLCK and TIOCGPTPEER and TIOCSTI and TCXONC with leakage of memory in the flush_to_ldisc function. This flaw allows a local user to crash the system or read unauthorized random data from memory. | |||||
| CVE-2025-68214 | 1 Linux | 1 Linux Kernel | 2026-10-14 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running. | |||||
| CVE-2026-70183 | 2026-10-14 | N/A | 7.5 HIGH | ||
| Concurrent execution using shared resource with improper synchronization ('race condition') in ASP.NET Core allows an authorized attacker to elevate privileges over a network. | |||||
| CVE-2026-109954 | 2026-10-13 | N/A | 6.5 MEDIUM | ||
| Parse Server 5.4.0 before 8.6.96 and 9.0.0 before 9.10.2-alpha.5 shares transactional batch state across concurrent requests, letting any client's transactional batch request interfere with other clients' database writes. On PostgreSQL or MongoDB replica sets and sharded clusters, other clients' acknowledged writes are rolled back if the batch fails, and PostgreSQL transactions can remain open indefinitely, causing subsequent writes to fail. | |||||
| CVE-2026-109279 | 2026-10-13 | N/A | 2.5 LOW | ||
| ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 lacks proper synchronization when the security policy is accessed, so simultaneous reads and writes of the policy by multiple threads trigger a race condition that causes a heap buffer over-write. An attacker able to induce concurrent security policy access can crash the application, causing a denial of service. | |||||
| CVE-2026-109779 | 2026-10-13 | N/A | 4.2 MEDIUM | ||
| Race condition in the Networking: DNS component. This vulnerability was fixed in Firefox 158 and Thunderbird 158. | |||||
| CVE-2026-109765 | 2026-10-13 | N/A | 4.2 MEDIUM | ||
| Race condition, use-after-free in the Graphics: Text component. This vulnerability was fixed in Firefox 158, Firefox ESR 153.5, Thunderbird 158, and Thunderbird 153.5. | |||||
| CVE-2026-109719 | 2026-10-13 | N/A | 4.2 MEDIUM | ||
| Race condition, use-after-free in the Graphics: CanvasWebGL component. This vulnerability was fixed in Firefox 158, Firefox ESR 115.43, Firefox ESR 153.5, Thunderbird 158, and Thunderbird 153.5. | |||||
| CVE-2026-108830 | 2026-10-13 | 3.6 LOW | 4.2 MEDIUM | ||
| A weakness has been identified in meetecho janus-gateway up to 1.4.2. This affects an unknown part of the file src/plugins/janus_videoroom.c of the component VideoRoom. This manipulation causes race condition. Remote exploitation of the attack is possible. The attack's complexity is rated as high. It is indicated that the exploitability is difficult. The exploit has been made available to the public and could be used for attacks. Patch name: 27c0d1af888153e818675b56a4e6267f62d57097. Applying a patch is the recommended action to fix this issue. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product. | |||||
| CVE-2026-64031 | 1 Linux | 1 Linux Kernel | 2026-10-13 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: erofs: fix managed cache race for unaligned extents After unaligned compressed extents were introduced, the following race could occur: [Thread 1] [Thread 2] (z_erofs_fill_bio_vec) <handle a Z_EROFS_PREALLOCATED_FOLIO folio> ... filemap_add_folio (1) (z_erofs_bind_cache) <the same folio is found..> .. .. folio_attach_private (2) filemap_add_folio (3) again Since (1) is executed but (2) hasn't been executed yet, it's possible that another thread finds the same managed folio in z_erofs_bind_cache() for a different pcluster and calls filemap_add_folio() again since folio->private is still Z_EROFS_PREALLOCATED_FOLIO. Fix this by explicitly clearing folio->private before making the folio visible in the managed cache so that another pcluster can simply wait on the locked managed folio as what we did for other shared cases [1]. This only impacts unaligned data compression (`-E48bit` with zstd, for example). [1] Commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of crafted images properly") was originally introduced to handle crafted overlapped extents, but it addresses unaligned extents as well. | |||||
| CVE-2026-106385 | 1 Google | 1 Chrome | 2026-10-13 | N/A | 5.3 MEDIUM |
| Race condition in Chromoting in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to potentially bypass system access restrictions via crafted network traffic. (Chromium security severity: Low) | |||||
| CVE-2026-106500 | 1 Linuxfoundation | 2 Backstage, Backstage\/plugin-scaffolder-backend | 2026-10-13 | N/A | 8.5 HIGH |
| Backstage is an open framework for building developer portals. Prior to 3.3.1, 3.4.1, 4.0.3 and 4.1.0, the @backstage/plugin-scaffolder-backend package is affected by improper task state validation in scaffolder backend. An authenticated user with permission to create and access Scaffolder tasks may, under specific timing and deployment conditions, affect files accessible to the Backstage backend. If backend application files are writable, the confidentiality, integrity, and availability of the backend may be compromised. This issue is fixed in versions 3.3.1, 3.4.1, 4.0.3 and 4.1.0. | |||||
| CVE-2026-64010 | 1 Linux | 1 Linux Kernel | 2026-10-13 | N/A | 8.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc() A race condition exists in the NFC LLCP connection state machine where the connection acceptance packet (CC) can be processed concurrently with socket release. This can lead to a use-after-free of the socket object. When nfc_llcp_recv_cc() moves the socket from the connecting_sockets list to the sockets list, it does so without holding the socket lock. If llcp_sock_release() is executing concurrently, it might have already unlinked the socket and dropped its references, which can result in nfc_llcp_recv_cc() linking a freed socket into the live list. Fix this by holding lock_sock() during the state transition and list movement in nfc_llcp_recv_cc(). After acquiring the lock, check if the socket is still hashed to ensure it hasn't already been unlinked and marked for destruction by the release path. This aligns the locking pattern with recv_hdlc() and recv_disc(). | |||||
| CVE-2026-42689 | 2026-10-13 | N/A | 3.7 LOW | ||
| Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Pixelite Events Manager events-manager allows Leveraging Race Conditions.This issue affects Events Manager: from n/a through 7.4.7. | |||||
| CVE-2025-68749 | 1 Linux | 1 Linux Kernel | 2026-10-13 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind(). | |||||
| CVE-2025-15242 | 1 Phpems | 1 Phpems | 2026-10-13 | 2.1 LOW | 3.1 LOW |
| A vulnerability was detected in PHPEMS up to 11.0. The impacted element is an unknown function of the component Coupon Handler. Performing a manipulation results in race condition. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitability is regarded as difficult. The exploit is now public and may be used. | |||||