Total
1767 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2014-0245 | 1 Redhat | 1 Jboss Portal | 2024-11-21 | 4.3 MEDIUM | 5.9 MEDIUM |
| It was found that the implementation of the GTNSubjectCreatingInterceptor class in gatein-wsrp was not thread safe. For a specific WSRP endpoint, under high-concurrency scenarios or scenarios where SOAP messages take long to execute, it was possible for an unauthenticated remote attacker to gain privileged information if WS-Security is enabled for the WSRP Consumer, and the endpoint in question is being used by a privileged user. This affects JBoss Portal 6.2.0. | |||||
| CVE-2013-3685 | 2 Lg, Spritesoftware | 45 E971, E973, E975 and 42 more | 2024-11-21 | 6.9 MEDIUM | 7.0 HIGH |
| A Privilege Escalation Vulnerability exists in Sprite Software Spritebud 1.3.24 and 1.3.28 and Backup 2.5.4105 and 2.5.4108 on LG Android smartphones due to a race condition in the spritebud daemon, which could let a local malicious user obtain root privileges. | |||||
| 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-49866 | 1 Linux | 1 Linux Kernel | 2024-11-20 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. | |||||
| 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-49981 | 1 Linux | 1 Linux Kernel | 2024-11-08 | N/A | 7.0 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove. | |||||
| CVE-2024-47679 | 1 Linux | 1 Linux Kernel | 2024-11-08 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug. | |||||
| CVE-2024-50135 | 1 Linux | 1 Linux Kernel | 2024-11-08 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix race condition between reset and nvme_dev_disable() nvme_dev_disable() modifies the dev->online_queues field, therefore nvme_pci_update_nr_queues() should avoid racing against it, otherwise we could end up passing invalid values to blk_mq_update_nr_hw_queues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pci_irq_get_affinity+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace: <TASK> ? blk_mq_pci_map_queues+0x87/0x3c0 ? pci_irq_get_affinity+0x187/0x210 blk_mq_pci_map_queues+0x87/0x3c0 nvme_pci_map_queues+0x189/0x460 [nvme] blk_mq_update_nr_hw_queues+0x2a/0x40 nvme_reset_work+0x1be/0x2a0 [nvme] Fix the bug by locking the shutdown_lock mutex before using dev->online_queues. Give up if nvme_dev_disable() is running or if it has been executed already. | |||||
| CVE-2024-51515 | 1 Huawei | 1 Harmonyos | 2024-11-07 | N/A | 4.7 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 | 4.8 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. | |||||