Total
5555 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2008-5038 | 1 Novell | 1 Edirectory | 2025-04-09 | 10.0 HIGH | 9.8 CRITICAL |
| Use-after-free vulnerability in the NetWare Core Protocol (NCP) feature in Novell eDirectory 8.7.3 SP10 before 8.7.3 SP10 FTF1 and 8.8 SP2 for Windows allows remote attackers to cause a denial of service and possibly execute arbitrary code via a sequence of "Get NCP Extension Information By Name" requests that cause one thread to operate on memory after it has been freed in another thread, which triggers memory corruption, aka Novell Bug 373852. | |||||
| CVE-2009-3616 | 2 Qemu, Redhat | 3 Qemu, Enterprise Linux Server, Enterprise Linux Workstation | 2025-04-09 | 8.5 HIGH | 9.9 CRITICAL |
| Multiple use-after-free vulnerabilities in vnc.c in the VNC server in QEMU 0.10.6 and earlier might allow guest OS users to execute arbitrary code on the host OS by establishing a connection from a VNC client and then (1) disconnecting during data transfer, (2) sending a message using incorrect integer data types, or (3) using the Fuzzy Screen Mode protocol, related to double free vulnerabilities. | |||||
| CVE-2010-0249 | 1 Microsoft | 7 Internet Explorer, Windows 2000, Windows 7 and 4 more | 2025-04-09 | 9.3 HIGH | 8.8 HIGH |
| Use-after-free vulnerability in Microsoft Internet Explorer 6, 6 SP1, 7, and 8 on Windows 2000 SP4; Windows XP SP2 and SP3; Windows Server 2003 SP2; Windows Vista Gold, SP1, and SP2; Windows Server 2008 Gold, SP2, and R2; and Windows 7 allows remote attackers to execute arbitrary code by accessing a pointer associated with a deleted object, related to incorrectly initialized memory and improper handling of objects in memory, as exploited in the wild in December 2009 and January 2010 during Operation Aurora, aka "HTML Object Memory Corruption Vulnerability." | |||||
| CVE-2007-3929 | 1 Opera | 1 Opera Browser | 2025-04-09 | 9.3 HIGH | N/A |
| Use-after-free vulnerability in the BitTorrent support in Opera before 9.22 allows user-assisted remote attackers to execute arbitrary code via a crafted header in a torrent file, which leaves a dangling pointer to an invalid object. | |||||
| CVE-2025-3066 | 1 Google | 1 Chrome | 2025-04-08 | N/A | 8.8 HIGH |
| Use after free in Site Isolation in Google Chrome prior to 135.0.7049.84 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2024-27052 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-04-08 | N/A | 7.4 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work The workqueue might still be running, when the driver is stopped. To avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop(). | |||||
| CVE-2024-27394 | 1 Linux | 1 Linux Kernel | 2025-04-08 | N/A | 7.4 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: tcp: Fix Use-After-Free in tcp_ao_connect_init Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal of tcp_ao_connect_init, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe. | |||||
| CVE-2023-52629 | 1 Linux | 1 Linux Kernel | 2025-04-08 | N/A | 8.4 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: sh: push-switch: Reorder cleanup operations to avoid use-after-free bug The original code puts flush_work() before timer_shutdown_sync() in switch_drv_remove(). Although we use flush_work() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below: (cpu 0) | (cpu 1) switch_drv_remove() | flush_work() | ... | switch_timer // timer | schedule_work(&psw->work) timer_shutdown_sync() | ... | switch_work_handler // worker kfree(psw) // free | | psw->state = 0 // use This patch puts timer_shutdown_sync() before flush_work() to mitigate the bugs. As a result, the worker and timer will be stopped safely before the deallocate operations. | |||||
| CVE-2022-4379 | 2 Fedoraproject, Linux | 2 Fedora, Linux Kernel | 2025-04-08 | N/A | 7.5 HIGH |
| A use-after-free vulnerability was found in __nfs42_ssc_open() in fs/nfs/nfs4file.c in the Linux kernel. This flaw allows an attacker to conduct a remote denial | |||||
| CVE-2024-26939 | 1 Linux | 1 Linux Kernel | 2025-04-08 | N/A | 7.0 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/i915/vma: Fix UAF on destroy against retire race Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle. [161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915] [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915] [161.360592] RIP: 0010:debug_print_object+0x80/0xb0 ... [161.361347] debug_object_free+0xeb/0x110 [161.361362] i915_active_fini+0x14/0x130 [i915] [161.361866] release_references+0xfe/0x1f0 [i915] [161.362543] i915_vma_parked+0x1db/0x380 [i915] [161.363129] __gt_park+0x121/0x230 [i915] [161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915] That has been tracked down to be happening when another thread is deactivating the VMA inside __active_retire() helper, after the VMA's active counter has been already decremented to 0, but before deactivation of the VMA's object is reported to the object debugging tool. We could prevent from that race by serializing i915_active_fini() with __active_retire() via ref->tree_lock, but that wouldn't stop the VMA from being used, e.g. from __i915_vma_retire() called at the end of __active_retire(), after that VMA has been already freed by a concurrent i915_vma_destroy() on return from the i915_active_fini(). Then, we should rather fix the issue at the VMA level, not in i915_active. Since __i915_vma_parked() is called from __gt_park() on last put of the GT's wakeref, the issue could be addressed by holding the GT wakeref long enough for __active_retire() to complete before that wakeref is released and the GT parked. I believe the issue was introduced by commit d93939730347 ("drm/i915: Remove the vma refcount") which moved a call to i915_active_fini() from a dropped i915_vma_release(), called on last put of the removed VMA kref, to i915_vma_parked() processing path called on last put of a GT wakeref. However, its visibility to the object debugging tool was suppressed by a bug in i915_active that was fixed two weeks later with commit e92eb246feb9 ("drm/i915/active: Fix missing debug object activation"). A VMA associated with a request doesn't acquire a GT wakeref by itself. Instead, it depends on a wakeref held directly by the request's active intel_context for a GT associated with its VM, and indirectly on that intel_context's engine wakeref if the engine belongs to the same GT as the VMA's VM. Those wakerefs are released asynchronously to VMA deactivation. Fix the issue by getting a wakeref for the VMA's GT when activating it, and putting that wakeref only after the VMA is deactivated. However, exclude global GTT from that processing path, otherwise the GPU never goes idle. Since __i915_vma_retire() may be called from atomic contexts, use async variant of wakeref put. Also, to avoid circular locking dependency, take care of acquiring the wakeref before VM mutex when both are needed. v7: Add inline comments with justifications for: - using untracked variants of intel_gt_pm_get/put() (Nirmoy), - using async variant of _put(), - not getting the wakeref in case of a global GTT, - always getting the first wakeref outside vm->mutex. v6: Since __i915_vma_active/retire() callbacks are not serialized, storing a wakeref tracking handle inside struct i915_vma is not safe, and there is no other good place for that. Use untracked variants of intel_gt_pm_get/put_async(). v5: Replace "tile" with "GT" across commit description (Rodrigo), - ---truncated--- | |||||
| CVE-2022-3977 | 1 Linux | 1 Linux Kernel | 2025-04-08 | N/A | 7.8 HIGH |
| A use-after-free flaw was found in the Linux kernel MCTP (Management Component Transport Protocol) functionality. This issue occurs when a user simultaneously calls DROPTAG ioctl and socket close happens, which could allow a local user to crash the system or potentially escalate their privileges on the system. | |||||
| CVE-2025-31498 | 2025-04-08 | N/A | N/A | ||
| c-ares is an asynchronous resolver library. From 1.32.3 through 1.34.4, there is a use-after-free in read_answers() when process_answer() may re-enqueue a query either due to a DNS Cookie Failure or when the upstream server does not properly support EDNS, or possibly on TCP queries if the remote closed the connection immediately after a response. If there was an issue trying to put that new transaction on the wire, it would close the connection handle, but read_answers() was still expecting the connection handle to be available to possibly dequeue other responses. In theory a remote attacker might be able to trigger this by flooding the target with ICMP UNREACHABLE packets if they also control the upstream nameserver and can return a result with one of those conditions, this has been untested. Otherwise only a local attacker might be able to change system behavior to make send()/write() return a failure condition. This vulnerability is fixed in 1.34.5. | |||||
| CVE-2020-0674 | 1 Microsoft | 15 Internet Explorer, Windows 10 1507, Windows 10 1607 and 12 more | 2025-04-08 | 7.6 HIGH | 7.5 HIGH |
| A remote code execution vulnerability exists in the way that the scripting engine handles objects in memory in Internet Explorer, aka 'Scripting Engine Memory Corruption Vulnerability'. This CVE ID is unique from CVE-2020-0673, CVE-2020-0710, CVE-2020-0711, CVE-2020-0712, CVE-2020-0713, CVE-2020-0767. | |||||
| CVE-2025-21893 | 1 Linux | 1 Linux Kernel | 2025-04-08 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: keys: Fix UAF in key_put() Once a key's reference count has been reduced to 0, the garbage collector thread may destroy it at any time and so key_put() is not allowed to touch the key after that point. The most key_put() is normally allowed to do is to touch key_gc_work as that's a static global variable. However, in an effort to speed up the reclamation of quota, this is now done in key_put() once the key's usage is reduced to 0 - but now the code is looking at the key after the deadline, which is forbidden. Fix this by using a flag to indicate that a key can be gc'd now rather than looking at the key's refcount in the garbage collector. | |||||
| CVE-2022-48697 | 1 Linux | 1 Linux Kernel | 2025-04-08 | N/A | 5.3 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a use-after-free Fix the following use-after-free complaint triggered by blktests nvme/004: BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350 Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460 Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop] Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e print_report.cold+0x36/0x1e2 kasan_report+0xb9/0xf0 __asan_load4+0x6b/0x80 blk_mq_complete_request_remote+0xac/0x350 nvme_loop_queue_response+0x1df/0x275 [nvme_loop] __nvmet_req_complete+0x132/0x4f0 [nvmet] nvmet_req_complete+0x15/0x40 [nvmet] nvmet_execute_io_connect+0x18a/0x1f0 [nvmet] nvme_loop_execute_work+0x20/0x30 [nvme_loop] process_one_work+0x56e/0xa70 worker_thread+0x2d1/0x640 kthread+0x183/0x1c0 ret_from_fork+0x1f/0x30 | |||||
| CVE-2023-52566 | 1 Linux | 1 Linux Kernel | 2025-04-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential use after free in nilfs_gccache_submit_read_data() In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the reference count of bh when the call to nilfs_dat_translate() fails. If the reference count hits 0 and its owner page gets unlocked, bh may be freed. However, bh->b_page is dereferenced to put the page after that, which may result in a use-after-free bug. This patch moves the release operation after unlocking and putting the page. NOTE: The function in question is only called in GC, and in combination with current userland tools, address translation using DAT does not occur in that function, so the code path that causes this issue will not be executed. However, it is possible to run that code path by intentionally modifying the userland GC library or by calling the GC ioctl directly. [konishi.ryusuke@gmail.com: NOTE added to the commit log] | |||||
| CVE-2023-52576 | 1 Linux | 1 Linux Kernel | 2025-04-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: x86/mm, kexec, ima: Use memblock_free_late() from ima_free_kexec_buffer() The code calling ima_free_kexec_buffer() runs long after the memblock allocator has already been torn down, potentially resulting in a use after free in memblock_isolate_range(). With KASAN or KFENCE, this use after free will result in a BUG from the idle task, and a subsequent kernel panic. Switch ima_free_kexec_buffer() over to memblock_free_late() to avoid that bug. | |||||
| CVE-2023-38139 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2025-04-08 | N/A | 7.8 HIGH |
| Windows Kernel Elevation of Privilege Vulnerability | |||||
| CVE-2023-38160 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2025-04-08 | N/A | 5.5 MEDIUM |
| Windows TCP/IP Information Disclosure Vulnerability | |||||
| CVE-2023-29365 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2025-04-08 | N/A | 7.8 HIGH |
| Windows Media Remote Code Execution Vulnerability | |||||