Total
12453 CVE
CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
---|---|---|---|---|---|
CVE-2023-30774 | 2 Apple, Libtiff | 2 Macos, Libtiff | 2025-03-14 | N/A | 5.5 MEDIUM |
A vulnerability was found in the libtiff library. This flaw causes a heap buffer overflow issue via the TIFFTAG_INKNAMES and TIFFTAG_NUMBEROFINKS values. | |||||
CVE-2019-12483 | 2 Debian, Gpac | 2 Debian Linux, Gpac | 2025-03-14 | 6.8 MEDIUM | 7.8 HIGH |
An issue was discovered in GPAC 0.7.1. There is a heap-based buffer overflow in the function ReadGF_IPMPX_RemoveToolNotificationListener in odf/ipmpx_code.c in libgpac.a, as demonstrated by MP4Box. | |||||
CVE-2020-16304 | 3 Artifex, Canonical, Debian | 3 Ghostscript, Ubuntu Linux, Debian Linux | 2025-03-14 | 4.3 MEDIUM | 5.5 MEDIUM |
A buffer overflow vulnerability in image_render_color_thresh() in base/gxicolor.c of Artifex Software GhostScript v9.18 to v9.50 allows a remote attacker to escalate privileges via a crafted eps file. This is fixed in v9.51. | |||||
CVE-2020-16297 | 3 Artifex, Canonical, Debian | 3 Ghostscript, Ubuntu Linux, Debian Linux | 2025-03-14 | 4.3 MEDIUM | 5.5 MEDIUM |
A buffer overflow vulnerability in FloydSteinbergDitheringC() in contrib/gdevbjca.c of Artifex Software GhostScript v9.18 to v9.50 allows a remote attacker to cause a denial of service via a crafted PDF file. This is fixed in v9.51. | |||||
CVE-2023-36274 | 1 Gnu | 1 Libredwg | 2025-03-14 | N/A | 8.8 HIGH |
LibreDWG v0.11 to v0.12.5 was discovered to contain a heap buffer overflow via the function bit_write_TF at bits.c. | |||||
CVE-2023-36271 | 1 Gnu | 1 Libredwg | 2025-03-14 | N/A | 8.8 HIGH |
LibreDWG v0.10 to v0.12.5 was discovered to contain a heap buffer overflow via the function bit_wcs2nlen at bits.c. | |||||
CVE-2024-50854 | 1 Tendacn | 2 G3, G3 Firmware | 2025-03-14 | N/A | 8.8 HIGH |
Tenda G3 v3.0 v15.11.0.20 was discovered to contain a stack overflow via the formSetPortMapping function. | |||||
CVE-2024-31956 | 1 Samsung | 6 Exynos 1480, Exynos 1480 Firmware, Exynos 2200 and 3 more | 2025-03-14 | N/A | 8.4 HIGH |
An issue was discovered in Samsung Mobile Processor Exynos 2200, Exynos 1480, Exynos 2400. It lacks proper buffer length checking, which can result in an Out-of-Bounds Write. | |||||
CVE-2024-27365 | 1 Samsung | 18 Exynos 1080, Exynos 1080 Firmware, Exynos 1280 and 15 more | 2025-03-14 | N/A | 4.4 MEDIUM |
An issue was discovered in Samsung Mobile Processor Exynos Exynos 980, Exynos 850, Exynos 1080, Exynos 1280, Exynos 1380, Exynos 1330, Exynos 1480, Exynos W920, Exynos W930. In the function slsi_rx_blockack_ind(), there is no input validation check on a length coming from userspace, which can lead to a potential heap over-read. | |||||
CVE-2021-27562 | 1 Arm | 1 Trusted Firmware-m | 2025-03-14 | 4.9 MEDIUM | 5.5 MEDIUM |
In Arm Trusted Firmware M through 1.2, the NS world may trigger a system halt, an overwrite of secure data, or the printing out of secure data when calling secure functions under the NSPE handler mode. | |||||
CVE-2024-46258 | 1 Randygaul | 1 Cute Png | 2025-03-14 | N/A | 7.8 HIGH |
cute_png v1.05 was discovered to contain a heap buffer overflow via the cp_load_png_mem() function at cute_png.h. | |||||
CVE-2024-39118 | 1 Mommyheather | 1 Advanced Backups | 2025-03-14 | N/A | 5.5 MEDIUM |
Mommy Heather Advanced Backups up to v3.5.3 allows attackers to write arbitrary files via restoring a crafted back up. | |||||
CVE-2024-2615 | 1 Mozilla | 1 Firefox | 2025-03-14 | N/A | 9.8 CRITICAL |
Memory safety bugs present in Firefox 123. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 124. | |||||
CVE-2024-46276 | 1 Randygaul | 1 Cute Png | 2025-03-14 | N/A | 7.8 HIGH |
cute_png v1.05 was discovered to contain a heap buffer overflow via the cp_chunk() function at cute_png.h. | |||||
CVE-2024-37079 | 1 Vmware | 2 Cloud Foundation, Vcenter Server | 2025-03-14 | N/A | 9.8 CRITICAL |
vCenter Server contains a heap-overflow vulnerability in the implementation of the DCERPC protocol. A malicious actor with network access to vCenter Server may trigger this vulnerability by sending a specially crafted network packet potentially leading to remote code execution. | |||||
CVE-2023-32873 | 2 Google, Mediatek | 25 Android, Mt6761, Mt6765 and 22 more | 2025-03-13 | N/A | 6.7 MEDIUM |
In keyInstall, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08583919; Issue ID: ALPS08304227. | |||||
CVE-2021-47132 | 1 Linux | 1 Linux Kernel | 2025-03-13 | N/A | 7.1 HIGH |
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix sk_forward_memory corruption on retransmission MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. | |||||
CVE-2021-47152 | 1 Linux | 1 Linux Kernel | 2025-03-13 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix data stream corruption Maxim reported several issues when forcing a TCP transparent proxy to use the MPTCP protocol for the inbound connections. He also provided a clean reproducer. The problem boils down to 'mptcp_frag_can_collapse_to()' assuming that only MPTCP will use the given page_frag. If others - e.g. the plain TCP protocol - allocate page fragments, we can end-up re-using already allocated memory for mptcp_data_frag. Fix the issue ensuring that the to-be-expanded data fragment is located at the current page frag end. v1 -> v2: - added missing fixes tag (Mat) | |||||
CVE-2025-21865 | 1 Linux | 1 Linux Kernel | 2025-03-13 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl(). Brad Spengler reported the list_del() corruption splat in gtp_net_exit_batch_rtnl(). [0] Commit eb28fd76c0a0 ("gtp: Destroy device along with udp socket's netns dismantle.") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl() to destroy devices in each netns as done in geneve and ip tunnels. However, this could trigger ->dellink() twice for the same device during ->exit_batch_rtnl(). Say we have two netns A & B and gtp device B that resides in netns B but whose UDP socket is in netns A. 1. cleanup_net() processes netns A and then B. 2. gtp_net_exit_batch_rtnl() finds the device B while iterating netns A's gn->gtp_dev_list and calls ->dellink(). [ device B is not yet unlinked from netns B as unregister_netdevice_many() has not been called. ] 3. gtp_net_exit_batch_rtnl() finds the device B while iterating netns B's for_each_netdev() and calls ->dellink(). gtp_dellink() cleans up the device's hash table, unlinks the dev from gn->gtp_dev_list, and calls unregister_netdevice_queue(). Basically, calling gtp_dellink() multiple times is fine unless CONFIG_DEBUG_LIST is enabled. Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() and delegate the destruction to default_device_exit_batch() as done in bareudp. [0]: list_del corruption, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04) kernel BUG at lib/list_debug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:[<ffffffff84947381>] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60 RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283 RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054 RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000 RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32 R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4 R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08 RBX: kasan shadow of 0x0 RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554 RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71 RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object] RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ] R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ] R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ] R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object] FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0 Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d Call Trace: <TASK> [<ffffffff8a0c360d>] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [<ffffffff8a0c360d>] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [<ffffffff8a0c360d>] list_del include/linux/list.h:262 [inl ---truncated--- | |||||
CVE-2021-47138 | 1 Linux | 1 Linux Kernel | 2025-03-13 | N/A | 7.1 HIGH |
In the Linux kernel, the following vulnerability has been resolved: cxgb4: avoid accessing registers when clearing filters Hardware register having the server TID base can contain invalid values when adapter is in bad state (for example, due to AER fatal error). Reading these invalid values in the register can lead to out-of-bound memory access. So, fix by using the saved server TID base when clearing filters. |