Total
7305 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-11155 | 1 Rockwellautomation | 1 Arena | 2025-04-14 | N/A | 7.8 HIGH |
| A “use after free” code execution vulnerability exists in the Rockwell Automation Arena® that could allow a threat actor to craft a DOE file and force the software to use a resource that was already used. If exploited, a threat actor could leverage this vulnerability to execute arbitrary code. To exploit this vulnerability, a legitimate user must execute the malicious code crafted by the threat actor. | |||||
| CVE-2024-25763 | 1 Opennds | 1 Opennds | 2025-04-14 | N/A | 5.5 MEDIUM |
| openNDS 10.2.0 is vulnerable to Use-After-Free via /openNDS/src/auth.c. | |||||
| CVE-2024-9826 | 2 Autodesk, Microsoft | 9 Autocad, Autocad Advance Steel, Autocad Architecture and 6 more | 2025-04-11 | N/A | 7.8 HIGH |
| A maliciously crafted 3DM file when parsed in atf_api.dll through Autodesk AutoCAD can force a Use-After-Free vulnerability. A malicious actor can leverage this vulnerability to cause a crash, write sensitive data, or execute arbitrary code in the context of the current process. | |||||
| CVE-2024-8595 | 2 Autodesk, Microsoft | 9 Autocad, Autocad Advance Steel, Autocad Architecture and 6 more | 2025-04-11 | N/A | 7.8 HIGH |
| A maliciously crafted MODEL file when parsed in libodxdll.dll through Autodesk AutoCAD can force a Use-After-Free vulnerability. A malicious actor can leverage this vulnerability to cause a crash, write sensitive data, or execute arbitrary code in the context of the current process. | |||||
| CVE-2024-8590 | 2 Autodesk, Microsoft | 9 Autocad, Autocad Advance Steel, Autocad Architecture and 6 more | 2025-04-11 | N/A | 7.8 HIGH |
| A maliciously crafted 3DM file when parsed in atf_api.dll through Autodesk AutoCAD can force a Use-After-Free vulnerability. A malicious actor can leverage this vulnerability to cause a crash, write sensitive data, or execute arbitrary code in the context of the current process. | |||||
| CVE-2023-42459 | 1 Eprosima | 1 Fast Dds | 2025-04-11 | N/A | 8.6 HIGH |
| Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group). In affected versions specific DATA submessages can be sent to a discovery locator which may trigger a free error. This can remotely crash any Fast-DDS process. The call to free() could potentially leave the pointer in the attackers control which could lead to a double free. This issue has been addressed in versions 2.12.0, 2.11.3, 2.10.3, and 2.6.7. Users are advised to upgrade. There are no known workarounds for this vulnerability. | |||||
| CVE-2024-30378 | 1 Juniper | 21 Junos, Mx, Mx10 and 18 more | 2025-04-11 | N/A | 5.5 MEDIUM |
| A Use After Free vulnerability in command processing of Juniper Networks Junos OS on MX Series allows a local, authenticated attacker to cause the broadband edge service manager daemon (bbe-smgd) to crash upon execution of specific CLI commands, creating a Denial of Service (DoS) condition. The process crashes and restarts automatically. When specific CLI commands are executed, the bbe-smgd daemon attempts to write into an area of memory (mgd socket) that was already closed, causing the process to crash. This process manages and controls the configuration of broadband subscriber sessions and services. While the process is unavailable, additional subscribers will not be able to connect to the device, causing a temporary Denial of Service condition. This issue only occurs if Graceful Routing Engine Switchover (GRES) and Subscriber Management are enabled. This issue affects Junos OS: * All versions before 20.4R3-S5, * from 21.1 before 21.1R3-S4, * from 21.2 before 21.2R3-S3, * from 21.3 before 21.3R3-S5, * from 21.4 before 21.4R3-S5, * from 22.1 before 22.1R3, * from 22.2 before 22.2R3, * from 22.3 before 22.3R2; | |||||
| CVE-2024-50217 | 1 Linux | 1 Linux Kernel | 2025-04-11 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 → loop0 fs_device \ btrfs_device_2 → loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) // btrfs_device_1->bdev_file is freed btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device(). | |||||
| CVE-2023-38703 | 1 Teluu | 1 Pjsip | 2025-04-10 | N/A | 9.8 CRITICAL |
| PJSIP is a free and open source multimedia communication library written in C with high level API in C, C++, Java, C#, and Python languages. SRTP is a higher level media transport which is stacked upon a lower level media transport such as UDP and ICE. Currently a higher level transport is not synchronized with its lower level transport that may introduce use-after-free issue. This vulnerability affects applications that have SRTP capability (`PJMEDIA_HAS_SRTP` is set) and use underlying media transport other than UDP. This vulnerability’s impact may range from unexpected application termination to control flow hijack/memory corruption. The patch is available as a commit in the master branch. | |||||
| CVE-2022-47093 | 1 Gpac | 1 Gpac | 2025-04-10 | N/A | 7.8 HIGH |
| GPAC MP4box 2.1-DEV-rev574-g9d5bb184b is vulnerable to heap use-after-free via filters/dmx_m2ts.c:470 in m2tsdmx_declare_pid | |||||
| CVE-2025-0995 | 1 Google | 1 Chrome | 2025-04-10 | N/A | 8.8 HIGH |
| Use after free in V8 in Google Chrome prior to 133.0.6943.98 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2022-25722 | 1 Qualcomm | 156 Apq8096au, Apq8096au Firmware, Ar9380 and 153 more | 2025-04-09 | N/A | 6.0 MEDIUM |
| Information exposure in DSP services due to improper handling of freeing memory | |||||
| CVE-2022-4382 | 1 Linux | 1 Linux Kernel | 2025-04-09 | N/A | 6.4 MEDIUM |
| A use-after-free flaw caused by a race among the superblock operations in the gadgetfs Linux driver was found. It could be triggered by yanking out a device that is running the gadgetfs side. | |||||
| 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-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-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. | |||||