Total
7305 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| 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 | |||||
| CVE-2023-29358 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2025-04-08 | N/A | 7.8 HIGH |
| Windows GDI Elevation of Privilege Vulnerability | |||||
| CVE-2023-29361 | 1 Microsoft | 5 Windows 10 21h2, Windows 10 22h2, Windows 11 21h2 and 2 more | 2025-04-08 | N/A | 7.0 HIGH |
| Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability | |||||
| CVE-2025-0444 | 1 Google | 1 Chrome | 2025-04-08 | N/A | 6.3 MEDIUM |
| Use after free in Skia in Google Chrome prior to 133.0.6943.53 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2025-0445 | 1 Google | 1 Chrome | 2025-04-08 | N/A | 5.4 MEDIUM |
| Use after free in V8 in Google Chrome prior to 133.0.6943.53 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2025-0997 | 1 Google | 1 Chrome | 2025-04-07 | N/A | 8.1 HIGH |
| Use after free in Navigation in Google Chrome prior to 133.0.6943.98 allowed a remote attacker to potentially exploit heap corruption via a crafted Chrome Extension. (Chromium security severity: High) | |||||
| CVE-2025-1006 | 1 Google | 1 Chrome | 2025-04-07 | N/A | 8.8 HIGH |
| Use after free in Network in Google Chrome prior to 133.0.6943.126 allowed a remote attacker to potentially exploit heap corruption via a crafted web app. (Chromium security severity: Medium) | |||||
| CVE-2024-35843 | 1 Linux | 1 Linux Kernel | 2025-04-07 | N/A | 6.8 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Use device rbtree in iopf reporting path The existing I/O page fault handler currently locates the PCI device by calling pci_get_domain_bus_and_slot(). This function searches the list of all PCI devices until the desired device is found. To improve lookup efficiency, replace it with device_rbtree_find() to search the device within the probed device rbtree. The I/O page fault is initiated by the device, which does not have any synchronization mechanism with the software to ensure that the device stays in the probed device tree. Theoretically, a device could be released by the IOMMU subsystem after device_rbtree_find() and before iopf_get_dev_fault_param(), which would cause a use-after-free problem. Add a mutex to synchronize the I/O page fault reporting path and the IOMMU release device path. This lock doesn't introduce any performance overhead, as the conflict between I/O page fault reporting and device releasing is very rare. | |||||
| CVE-2024-35854 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-04-07 | N/A | 8.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash The rehash delayed work migrates filters from one region to another according to the number of available credits. The migrated from region is destroyed at the end of the work if the number of credits is non-negative as the assumption is that this is indicative of migration being complete. This assumption is incorrect as a non-negative number of credits can also be the result of a failed migration. The destruction of a region that still has filters referencing it can result in a use-after-free [1]. Fix by not destroying the region if migration failed. [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858 CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70 mlxsw_sp_acl_atcam_entry_del+0x81/0x210 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 174: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Freed by task 7: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_region_destroy+0x272/0x310 mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 | |||||
| CVE-2025-2136 | 1 Google | 1 Chrome | 2025-04-07 | N/A | 8.8 HIGH |
| Use after free in Inspector in Google Chrome prior to 134.0.6998.88 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium) | |||||
| CVE-2022-36449 | 1 Arm | 3 Bifrost Gpu Kernel Driver, Midgard Gpu Kernel Driver, Valhall Gpu Kernel Driver | 2025-04-07 | N/A | 6.5 MEDIUM |
| An issue was discovered in the Arm Mali GPU Kernel Driver. A non-privileged user can make improper GPU processing operations to gain access to already freed memory, write a limited amount outside of buffer bounds, or to disclose details of memory mappings. This affects Midgard r4p0 through r32p0, Bifrost r0p0 through r38p0 and r39p0 before r38p1, and Valhall r19p0 through r38p0 and r39p0 before r38p1. | |||||
| CVE-2024-5688 | 1 Mozilla | 2 Firefox, Thunderbird | 2025-04-04 | N/A | 8.1 HIGH |
| If a garbage collection was triggered at the right time, a use-after-free could have occurred during object transplant. This vulnerability affects Firefox < 127, Firefox ESR < 115.12, and Thunderbird < 115.12. | |||||
| CVE-2024-5702 | 1 Mozilla | 2 Firefox, Thunderbird | 2025-04-04 | N/A | 7.5 HIGH |
| Memory corruption in the networking stack could have led to a potentially exploitable crash. This vulnerability affects Firefox < 125, Firefox ESR < 115.12, and Thunderbird < 115.12. | |||||
| CVE-2024-26737 | 1 Linux | 1 Linux Kernel | 2025-04-04 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel The following race is possible between bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer. bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t); /* UAF on t */ hrtimer_cancel(&t->timer); In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu grace period. This requires a rcu_head addition to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer has not been visible by others yet. In bpf_timer_cancel, rcu_read_lock() is added because this helper can be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of the spin_lock. Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free, it busy waits for the flag to be cleared before kfree(t). This patch goes with a straight forward solution and frees timer->timer after a rcu grace period. | |||||
| CVE-2024-35986 | 1 Linux | 1 Linux Kernel | 2025-04-04 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered The power_supply frame-work is not really designed for there to be long living in kernel references to power_supply devices. Specifically unregistering a power_supply while some other code has a reference to it triggers a WARN in power_supply_unregister(): WARN_ON(atomic_dec_return(&psy->use_cnt)); Folllowed by the power_supply still getting removed and the backing data freed anyway, leaving the tusb1210 charger-detect code with a dangling reference, resulting in a crash the next time tusb1210_get_online() is called. Fix this by only holding the reference in tusb1210_get_online() freeing it at the end of the function. Note this still leaves a theoretical race window, but it avoids the issue when manually rmmod-ing the charger chip driver during development. | |||||