Total
1934 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2012-0953 | 1 Nvidia | 1 Display Driver | 2024-11-21 | 4.4 MEDIUM | 5.0 MEDIUM |
| A race condition was discovered in the Linux drivers for Nvidia graphics which allowed an attacker to exfiltrate kernel memory to userspace. This issue was fixed in version 295.53. | |||||
| CVE-2011-3585 | 2 Redhat, Samba | 2 Enterprise Linux, Samba | 2024-11-21 | 1.9 LOW | 4.7 MEDIUM |
| Multiple race conditions in the (1) mount.cifs and (2) umount.cifs programs in Samba 3.6 allow local users to cause a denial of service (mounting outage) via a SIGKILL signal during a time window when the /etc/mtab~ file exists. | |||||
| CVE-2011-1075 | 1 Freebsd | 1 Freebsd | 2024-11-21 | 4.3 MEDIUM | 3.7 LOW |
| FreeBSD's crontab calculates the MD5 sum of the previous and new cronjob to determine if any changes have been made before copying the new version in. In particular, it uses the MD5File() function, which takes a pathname as an argument, and is called with euid 0. A race condition in this process may lead to an arbitrary MD5 comparison regardless of the read permissions. | |||||
| CVE-2011-0699 | 1 Linux | 1 Linux Kernel | 2024-11-21 | 6.9 MEDIUM | 7.0 HIGH |
| Integer signedness error in the btrfs_ioctl_space_info function in the Linux kernel 2.6.37 allows local users to cause a denial of service (heap-based buffer overflow) or possibly have unspecified other impact via a crafted slot value. | |||||
| CVE-2009-5152 | 1 Absolute | 1 Computrace Agent | 2024-11-21 | 1.9 LOW | 4.1 MEDIUM |
| Absolute Computrace Agent, as distributed on certain Dell Inspiron systems through 2009, has a race condition with the Dell Client Configuration Utility (DCCU), which allows privileged local users to change Computrace Agent's activation/deactivation status to the factory default via a crafted TaskResult.xml file. | |||||
| CVE-2009-4011 | 1 Dtc-xen Project | 1 Dtc-xen | 2024-11-21 | 6.8 MEDIUM | 8.1 HIGH |
| dtc-xen 0.5.x before 0.5.4 suffers from a race condition where an attacker could potentially get a bash access as xenXX user on the dom0, and then access a potentially reuse an already opened VPS console. | |||||
| CVE-2007-4774 | 1 Linux | 1 Linux Kernel | 2024-11-21 | 4.3 MEDIUM | 5.9 MEDIUM |
| The Linux kernel before 2.4.36-rc1 has a race condition. It was possible to bypass systrace policies by flooding the ptraced process with SIGCONT signals, which can can wake up a PTRACED process. | |||||
| CVE-2006-4245 | 2 Archivemail Project, Debian | 2 Archivemail, Debian Linux | 2024-11-21 | 6.8 MEDIUM | 8.1 HIGH |
| archivemail 0.6.2 uses temporary files insecurely leading to a possible race condition. | |||||
| CVE-2005-2352 | 1 Gs-gpl Project | 1 Gs-gpl | 2024-11-20 | 6.8 MEDIUM | 8.1 HIGH |
| I race condition in Temp files was found in gs-gpl before 8.56 addons scripts. | |||||
| CVE-2024-29211 | 1 Ivanti | 1 Secure Access Client | 2024-11-14 | N/A | 4.7 MEDIUM |
| A race condition in Ivanti Secure Access Client before version 22.7R4 allows a local authenticated attacker to modify sensitive configuration files. | |||||
| CVE-2024-49872 | 1 Linux | 1 Linux Kernel | 2024-11-13 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the "while start_idx" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error. | |||||
| CVE-2024-49864 | 1 Linux | 1 Linux Kernel | 2024-11-13 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread. | |||||
| CVE-2024-51515 | 1 Huawei | 1 Harmonyos | 2024-11-07 | N/A | 6.2 MEDIUM |
| Race condition vulnerability in the kernel network module Impact:Successful exploitation of this vulnerability may affect availability. | |||||
| CVE-2024-47827 | 1 Argo Workflows Project | 1 Argo Workflows | 2024-11-05 | N/A | 5.7 MEDIUM |
| Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Due to a race condition in a global variable in 3.6.0-rc1, the argo workflows controller can be made to crash on-command by any user with access to execute a workflow. This vulnerability is fixed in 3.6.0-rc2. | |||||
| CVE-2024-10468 | 1 Mozilla | 2 Firefox, Thunderbird | 2024-11-04 | N/A | 5.3 MEDIUM |
| Potential race conditions in IndexedDB could have caused memory corruption, leading to a potentially exploitable crash. This vulnerability affects Firefox < 132 and Thunderbird < 132. | |||||
| CVE-2024-47974 | 2024-10-31 | N/A | 4.4 MEDIUM | ||
| Race condition during resource shutdown in some Solidigm DC Products may allow an attacker to potentially enable denial of service. | |||||
| CVE-2024-47968 | 2024-10-31 | N/A | 4.4 MEDIUM | ||
| Improper resource shutdown in middle of certain operations on some Solidigm DC Products may allow an attacker to potentially enable denial of service. | |||||
| CVE-2022-49001 | 1 Linux | 1 Linux Kernel | 2024-10-30 | N/A | 7.0 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: riscv: fix race when vmap stack overflow Currently, when detecting vmap stack overflow, riscv firstly switches to the so called shadow stack, then use this shadow stack to call the get_overflow_stack() to get the overflow stack. However, there's a race here if two or more harts use the same shadow stack at the same time. To solve this race, we introduce spin_shadow_stack atomic var, which will be swap between its own address and 0 in atomic way, when the var is set, it means the shadow_stack is being used; when the var is cleared, it means the shadow_stack isn't being used. [Palmer: Add AQ to the swap, and also some comments.] | |||||
| CVE-2022-48989 | 1 Linux | 1 Linux Kernel | 2024-10-25 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: fscache: Fix oops due to race with cookie_lru and use_cookie If a cookie expires from the LRU and the LRU_DISCARD flag is set, but the state machine has not run yet, it's possible another thread can call fscache_use_cookie and begin to use it. When the cookie_worker finally runs, it will see the LRU_DISCARD flag set, transition the cookie->state to LRU_DISCARDING, which will then withdraw the cookie. Once the cookie is withdrawn the object is removed the below oops will occur because the object associated with the cookie is now NULL. Fix the oops by clearing the LRU_DISCARD bit if another thread uses the cookie before the cookie_worker runs. BUG: kernel NULL pointer dereference, address: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G E 6.0.0-5.dneg.x86_64 #1 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Workqueue: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... Call Trace: netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 kthread+0xd6/0x100 | |||||
| CVE-2024-47741 | 1 Linux | 1 Linux Kernel | 2024-10-23 | N/A | 7.0 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future. | |||||