Total
6793 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-54030 | 2 Openatom, Openharmony | 2 Openharmony, Openharmony | 2025-10-16 | 4.4 Medium |
| in OpenHarmony v4.1.2 and prior versions allow a local attacker cause DOSÂ through use after free. | ||||
| CVE-2023-48184 | 1 Quickjs Project | 1 Quickjs | 2025-10-15 | 3.9 Low |
| QuickJS before 7414e5f has a quickjs.h JS_FreeValueRT use-after-free because of incorrect garbage collection of async functions with closures. | ||||
| CVE-2024-36353 | 2025-10-14 | 6.5 Medium | ||
| Insufficient clearing of GPU global memory could allow a malicious process running on the same GPU to read left over memory values potentially leading to loss of confidentiality. | ||||
| CVE-2023-36041 | 1 Microsoft | 4 365 Apps, Excel, Office and 1 more | 2025-10-08 | 7.8 High |
| Microsoft Excel Remote Code Execution Vulnerability | ||||
| CVE-2023-36008 | 1 Microsoft | 1 Edge Chromium | 2025-10-08 | 6.6 Medium |
| Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability | ||||
| CVE-2023-36034 | 1 Microsoft | 1 Edge Chromium | 2025-10-08 | 7.3 High |
| Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability | ||||
| CVE-2025-5100 | 1 Dynamixsoftware | 1 Printershare | 2025-10-08 | 8 High |
| A double-free condition occurs during the cleanup of temporary image files, which can be exploited to achieve memory corruption and potentially arbitrary code execution. | ||||
| CVE-2024-42326 | 1 Zabbix | 1 Zabbix | 2025-10-08 | 4.4 Medium |
| There was discovered a use after free bug in browser.c in the es_browser_get_variant function | ||||
| CVE-2024-42112 | 1 Linux | 1 Linux Kernel | 2025-10-07 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: txgbe: free isb resources at the right time When using MSI/INTx interrupt, the shared interrupts are still being handled in the device remove routine, before free IRQs. So isb memory is still read after it is freed. Thus move wx_free_isb_resources() from txgbe_close() to txgbe_remove(). And fix the improper isb free action in txgbe_open() error handling path. | ||||
| CVE-2025-61692 | 1 Keyence | 1 Vt Studio | 2025-10-07 | 7.8 High |
| VT STUDIO versions 8.53 and prior contain a use after free vulnerability. If the product uses a specially crafted file, arbitrary code may be executed on the affected product. | ||||
| CVE-2024-45544 | 1 Qualcomm | 88 C-v2x 9150, C-v2x 9150 Firmware, Fastconnect 6800 and 85 more | 2025-10-06 | 6.6 Medium |
| Memory corruption while processing IOCTL calls to add route entry in the HW. | ||||
| CVE-2024-45540 | 1 Qualcomm | 136 C-v2x 9150, C-v2x 9150 Firmware, Fastconnect 6200 and 133 more | 2025-10-06 | 6.6 Medium |
| Memory corruption while invoking IOCTL map buffer request from userspace. | ||||
| CVE-2024-43066 | 1 Qualcomm | 196 Csrb31024, Csrb31024 Firmware, Fastconnect 6200 and 193 more | 2025-10-06 | 7.8 High |
| Memory corruption while handling file descriptor during listener registration/de-registration. | ||||
| CVE-2024-49848 | 1 Qualcomm | 294 Ar8035, Ar8035 Firmware, Fastconnect 6200 and 291 more | 2025-10-06 | 6.7 Medium |
| Memory corruption while processing multiple IOCTL calls from HLOS to DSP. | ||||
| CVE-2025-9385 | 2 Appneta, Broadcom | 2 Tcpreplay, Tcpreplay | 2025-10-06 | 5.3 Medium |
| A flaw has been found in appneta tcpreplay up to 4.5.1. The affected element is the function fix_ipv6_checksums of the file edit_packet.c of the component tcprewrite. This manipulation causes use after free. The attack is restricted to local execution. The exploit has been published and may be used. Upgrading to version 4.5.2-beta3 is sufficient to fix this issue. It is advisable to upgrade the affected component. | ||||
| CVE-2025-9386 | 2 Appneta, Broadcom | 2 Tcpreplay, Tcpreplay | 2025-10-06 | 5.3 Medium |
| A vulnerability has been found in appneta tcpreplay up to 4.5.1. The impacted element is the function get_l2len_protocol of the file get.c of the component tcprewrite. Such manipulation leads to use after free. The attack must be carried out locally. The exploit has been disclosed to the public and may be used. Upgrading to version 4.5.2-beta3 is sufficient to resolve this issue. You should upgrade the affected component. | ||||
| CVE-2024-23365 | 1 Qualcomm | 96 Fastconnect 7800, Fastconnect 7800 Firmware, Qam8255p and 93 more | 2025-10-03 | 8.4 High |
| Memory corruption while releasing shared resources in MinkSocket listener thread. | ||||
| CVE-2024-38629 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-10-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Avoid unnecessary destruction of file_ida file_ida is allocated during cdev open and is freed accordingly during cdev release. This sequence is guaranteed by driver file operations. Therefore, there is no need to destroy an already empty file_ida when the WQ cdev is removed. Worse, ida_free() in cdev release may happen after destruction of file_ida per WQ cdev. This can lead to accessing an id in file_ida after it has been destroyed, resulting in a kernel panic. Remove ida_destroy(&file_ida) to address these issues. | ||||
| CVE-2024-45434 | 1 Opensynergy | 1 Blue Sdk | 2025-10-02 | 9.8 Critical |
| OpenSynergy BlueSDK (aka Blue SDK) through 6.x has a Use-After-Free. The specific flaw exists within the BlueSDK Bluetooth stack. The issue results from the lack of validating the existence of an object before performing operations on the object (aka use after free). An attacker can leverage this to achieve remote code execution in the context of a user account under which the Bluetooth process runs. | ||||
| CVE-2025-21861 | 1 Linux | 1 Linux Kernel | 2025-10-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize() If migration succeeded, we called folio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from the old to the new folio. This will set memcg_data of the old folio to 0. Similarly, if migration failed, memcg_data of the dst folio is left unset. If we call folio_putback_lru() on such folios (memcg_data == 0), we will add the folio to be freed to the LRU, making memcg code unhappy. Running the hmm selftests: # ./hmm-tests ... # RUN hmm.hmm_device_private.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] <TASK> [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.116547][T14893] ? __warn.cold+0x110/0x210 [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.118667][T14893] ? report_bug+0x1b9/0x320 [ 102.119571][T14893] ? handle_bug+0x54/0x90 [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50 [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20 [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dump_page+0x4f/0x60 [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200 [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720 [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.129550][T14893] folio_putback_lru+0x16/0x80 [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530 [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80 Likely, nothing else goes wrong: putting the last folio reference will remove the folio from the LRU again. So besides memcg complaining, adding the folio to be freed to the LRU is just an unnecessary step. The new flow resembles what we have in migrate_folio_move(): add the dst to the lru, rem ---truncated--- | ||||