Vulnerabilities (CVE)

Filtered by CWE-415
Total 644 CVE
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2016-8618 1 Haxx 1 Curl 2024-11-21 7.5 HIGH 5.3 MEDIUM
The libcurl API function called `curl_maprintf()` before version 7.51.0 can be tricked into doing a double-free due to an unsafe `size_t` multiplication, on systems using 32 bit `size_t` variables.
CVE-2015-9165 1 Qualcomm 36 Ipq4019, Ipq4019 Firmware, Mdm9206 and 33 more 2024-11-21 10.0 HIGH 9.8 CRITICAL
In Android before 2018-04-05 or earlier security patch level on Qualcomm Snapdragon Mobile and Snapdragon Wear IPQ4019, MDM9206, MDM9607, MSM8909W, SD 210/SD 212/SD 205, SD 400, SD 410/12, SD 615/16/SD 415, SD 617, SD 650/52, SD 808, and SD 810, incorrect error handling could lead to a double free in QTEE file service API.
CVE-2011-2335 1 Google 1 Blink 2024-11-21 5.0 MEDIUM 7.5 HIGH
A double-free vulnerability exists in WebKit in Google Chrome before Blink M12 in the WebCore::CSSSelector function.
CVE-2011-1803 1 Google 1 Blink 2024-11-21 4.3 MEDIUM 6.5 MEDIUM
An issue exists in third_party/WebKit/Source/WebCore/svg/animation/SVGSMILElement.h in WebKit in Google Chrome before Blink M11 and M12 when trying to access a removed smil element.
CVE-2007-4773 1 Systrace Project 1 Systrace 2024-11-21 7.5 HIGH 9.8 CRITICAL
Systrace before 1.6.0 has insufficient escape policy enforcement.
CVE-2024-43447 1 Microsoft 1 Windows Server 2022 2024-11-19 N/A 8.1 HIGH
Windows SMBv3 Server Remote Code Execution Vulnerability
CVE-2024-50159 1 Linux 1 Linux Kernel 2024-11-19 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup() Clang static checker(scan-build) throws below warning: | drivers/firmware/arm_scmi/driver.c:line 2915, column 2 | Attempt to free released memory. When devm_add_action_or_reset() fails, scmi_debugfs_common_cleanup() will run twice which causes double free of 'dbg->name'. Remove the redundant scmi_debugfs_common_cleanup() to fix this problem.
CVE-2024-50152 1 Linux 1 Linux Kernel 2024-11-19 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix possible double free in smb2_set_ea() Clang static checker(scan-build) warning: fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory. 1304 | kfree(ea); | ^~~~~~~~~ There is a double free in such case: 'ea is initialized to NULL' -> 'first successful memory allocation for ea' -> 'something failed, goto sea_exit' -> 'first memory release for ea' -> 'goto replay_again' -> 'second goto sea_exit before allocate memory for ea' -> 'second memory release for ea resulted in double free'. Re-initialie 'ea' to NULL near to the replay_again label, it can fix this double free problem.
CVE-2024-43640 1 Microsoft 5 Windows 10 21h2, Windows 10 22h2, Windows 11 22h2 and 2 more 2024-11-18 N/A 7.8 HIGH
Windows Kernel-Mode Driver Elevation of Privilege Vulnerability
CVE-2024-49014 1 Microsoft 3 Sql Server 2016, Sql Server 2017, Sql Server 2019 2024-11-15 N/A 8.8 HIGH
SQL Server Native Client Remote Code Execution Vulnerability
CVE-2024-47426 1 Adobe 1 Substance 3d Painter 2024-11-13 N/A 7.8 HIGH
Substance3D - Painter versions 10.1.0 and earlier are affected by a Double Free vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
CVE-2024-45402 1 Dena 1 Picotls 2024-11-12 N/A 8.6 HIGH
Picotls is a TLS protocol library that allows users select different crypto backends based on their use case. When parsing a spoofed TLS handshake message, picotls (specifically, bindings within picotls that call the crypto libraries) may attempt to free the same memory twice. This double free occurs during the disposal of multiple objects without any intervening calls to malloc Typically, this triggers the malloc implementation to detect the error and abort the process. However, depending on the internals of malloc and the crypto backend being used, the flaw could potentially lead to a use-after-free scenario, which might allow for arbitrary code execution. The vulnerability is addressed with commit 9b88159ce763d680e4a13b6e8f3171ae923a535d.
CVE-2024-47404 1 Openatom 1 Openharmony 2024-11-06 N/A 8.4 HIGH
in OpenHarmony v4.1.0 and prior versions allow a local attacker cause the common permission is upgraded to root and sensitive information leak through double free.
CVE-2024-3187 2024-10-18 N/A 5.9 MEDIUM
This issue tracks two CWE-416 Use After Free (UAF) and one CWE-415 Double Free vulnerabilities in Goahead versions <= 6.0.0. These are caused by JST values not being nulled when freed during parsing of JST templates. If the ME_GOAHEAD_JAVASCRIPT flag is enabled, a remote attacker with the privileges to modify JavaScript template (JST) files could exploit this by providing malicious templates. This may lead to memory corruption, potentially causing a Denial of Service (DoS) or, in rare cases, code execution, though the latter is highly context-dependent.
CVE-2024-43514 1 Microsoft 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more 2024-10-17 N/A 7.8 HIGH
Windows Resilient File System (ReFS) Elevation of Privilege Vulnerability
CVE-2024-23379 1 Qualcomm 68 Fastconnect 6900, Fastconnect 6900 Firmware, Fastconnect 7800 and 65 more 2024-10-16 N/A 6.7 MEDIUM
Memory corruption while unmapping the fastrpc map when two threads can free the same map in concurrent scenario.
CVE-2024-46741 1 Linux 1 Linux Kernel 2024-09-20 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix double free of 'buf' in error path smatch warning: drivers/misc/fastrpc.c:1926 fastrpc_req_mmap() error: double free of 'buf' In fastrpc_req_mmap() error path, the fastrpc buffer is freed in fastrpc_req_munmap_impl() if unmap is successful. But in the end, there is an unconditional call to fastrpc_buf_free(). So the above case triggers the double free of fastrpc buf.
CVE-2023-7256 1 Tcpdump 1 Libpcap 2024-09-19 N/A 4.4 MEDIUM
In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns. This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block. A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400.
CVE-2024-38247 1 Microsoft 15 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 12 more 2024-09-17 N/A 7.8 HIGH
Windows Graphics Component Elevation of Privilege Vulnerability
CVE-2024-46687 1 Linux 1 Linux Kernel 2024-09-14 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk() [BUG] There is an internal report that KASAN is reporting use-after-free, with the following backtrace: BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs] Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45 CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x5e/0x2f0 print_report+0x118/0x216 kasan_report+0x11d/0x1f0 btrfs_check_read_bio+0xa68/0xb70 [btrfs] process_one_work+0xce0/0x12a0 worker_thread+0x717/0x1250 kthread+0x2e3/0x3c0 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x7d/0x80 kmem_cache_alloc_noprof+0x16e/0x3e0 mempool_alloc_noprof+0x12e/0x310 bio_alloc_bioset+0x3f0/0x7a0 btrfs_bio_alloc+0x2e/0x50 [btrfs] submit_extent_page+0x4d1/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 __kasan_slab_free+0x4b/0x60 kmem_cache_free+0x214/0x5d0 bio_free+0xed/0x180 end_bbio_data_read+0x1cc/0x580 [btrfs] btrfs_submit_chunk+0x98d/0x1880 [btrfs] btrfs_submit_bio+0x33/0x70 [btrfs] submit_one_bio+0xd4/0x130 [btrfs] submit_extent_page+0x3ea/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [CAUSE] Although I cannot reproduce the error, the report itself is good enough to pin down the cause. The call trace is the regular endio workqueue context, but the free-by-task trace is showing that during btrfs_submit_chunk() we already hit a critical error, and is calling btrfs_bio_end_io() to error out. And the original endio function called bio_put() to free the whole bio. This means a double freeing thus causing use-after-free, e.g.: 1. Enter btrfs_submit_bio() with a read bio The read bio length is 128K, crossing two 64K stripes. 2. The first run of btrfs_submit_chunk() 2.1 Call btrfs_map_block(), which returns 64K 2.2 Call btrfs_split_bio() Now there are two bios, one referring to the first 64K, the other referring to the second 64K. 2.3 The first half is submitted. 3. The second run of btrfs_submit_chunk() 3.1 Call btrfs_map_block(), which by somehow failed Now we call btrfs_bio_end_io() to handle the error 3.2 btrfs_bio_end_io() calls the original endio function Which is end_bbio_data_read(), and it calls bio_put() for the original bio. Now the original bio is freed. 4. The submitted first 64K bio finished Now we call into btrfs_check_read_bio() and tries to advance the bio iter. But since the original bio (thus its iter) is already freed, we trigger the above use-after free. And even if the memory is not poisoned/corrupted, we will later call the original endio function, causing a double freeing. [FIX] Instead of calling btrfs_bio_end_io(), call btrfs_orig_bbio_end_io(), which has the extra check on split bios and do the pr ---truncated---