Total
650 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-40676 | 2025-02-06 | 7.7 High | ||
| In checkKeyIntent of AccountManagerService.java, there is a possible way to bypass intent security check and install an unknown app due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2021-33970 | 1 Browser.360 | 1 Chrome | 2025-02-05 | 10 Critical |
| Buffer Overflow vulnerability in Qihoo 360 Chrome v13.0.2170.0 allows attacker to escalate priveleges. | ||||
| CVE-2021-21224 | 3 Debian, Fedoraproject, Google | 3 Debian Linux, Fedora, Chrome | 2025-02-05 | 8.8 High |
| Type confusion in V8 in Google Chrome prior to 90.0.4430.85 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. | ||||
| CVE-2020-6418 | 4 Debian, Fedoraproject, Google and 1 more | 7 Debian Linux, Fedora, Chrome and 4 more | 2025-02-05 | 8.8 High |
| Type confusion in V8 in Google Chrome prior to 80.0.3987.122 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. | ||||
| CVE-2020-16009 | 7 Cefsharp, Debian, Fedoraproject and 4 more | 9 Cefsharp, Debian Linux, Fedora and 6 more | 2025-02-05 | 8.8 High |
| Inappropriate implementation in V8 in Google Chrome prior to 86.0.4240.183 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. | ||||
| CVE-2023-24823 | 1 Riot-os | 1 Riot | 2025-02-04 | 9.8 Critical |
| RIOT-OS, an operating system that supports Internet of Things devices, contains a network stack with the ability to process 6LoWPAN frames. Prior to version 2022.10, an attacker can send a crafted frame to the device resulting in a type confusion between IPv6 extension headers and a UDP header. This occurs while encoding a 6LoWPAN IPHC header. The type confusion manifests in an out of bounds write in the packet buffer. The overflow can be used to corrupt other packets and the allocator metadata. Corrupting a pointer will easily lead to denial of service. While carefully manipulating the allocator metadata gives an attacker the possibility to write data to arbitrary locations and thus execute arbitrary code. Version 2022.10 fixes this issue. As a workaround, apply the patches manually. | ||||
| CVE-2021-30551 | 2 Fedoraproject, Google | 2 Fedora, Chrome | 2025-02-04 | 8.8 High |
| Type confusion in V8 in Google Chrome prior to 91.0.4472.101 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. | ||||
| CVE-2025-24129 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-01-31 | 7.5 High |
| A type confusion issue was addressed with improved checks. This issue is fixed in visionOS 2.3, iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, watchOS 11.3, tvOS 18.3. A remote attacker may cause an unexpected app termination. | ||||
| CVE-2025-0147 | 2025-01-30 | 8.8 High | ||
| Type confusion in the Zoom Workplace App for Linux before 6.2.10 may allow an authorized user to conduct an escalation of privilege via network access. | ||||
| CVE-2024-43498 | 4 Apple, Linux, Microsoft and 1 more | 6 Macos, Linux Kernel, .net and 3 more | 2025-01-30 | 9.8 Critical |
| .NET and Visual Studio Remote Code Execution Vulnerability | ||||
| CVE-2024-43596 | 1 Microsoft | 1 Edge Chromium | 2025-01-29 | 6.5 Medium |
| Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability | ||||
| CVE-2023-20673 | 2 Google, Mediatek | 43 Android, Iot Yocto, Mt5696 and 40 more | 2025-01-24 | 6.7 Medium |
| In vcu, there is a possible memory corruption due to type confusion. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519103; Issue ID: ALPS07519103. | ||||
| CVE-2024-13169 | 2025-01-24 | 7.8 High | ||
| An out-of-bounds read in Ivanti EPM before the 2024 January-2025 Security Update and 2022 SU6 January-2025 Security Update allows a local authenticated attacker to escalate their privileges. | ||||
| CVE-2024-26232 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-01-23 | 7.3 High |
| Microsoft Message Queuing (MSMQ) Remote Code Execution Vulnerability | ||||
| CVE-2024-20678 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-01-23 | 8.8 High |
| Remote Procedure Call Runtime Remote Code Execution Vulnerability | ||||
| CVE-2023-23557 | 1 Facebook | 1 Hermes | 2025-01-21 | 9.8 Critical |
| An error in Hermes' algorithm for copying objects properties prior to commit a00d237346894c6067a594983be6634f4168c9ad could be used by a malicious attacker to execute arbitrary code via type confusion. Note that this is only exploitable in cases where Hermes is used to execute untrusted JavaScript. Hence, most React Native applications are not affected. | ||||
| CVE-2023-25933 | 1 Facebook | 1 Hermes | 2025-01-21 | 9.8 Critical |
| A type confusion bug in TypedArray prior to commit e6ed9c1a4b02dc219de1648f44cd808a56171b81 could have been used by a malicious attacker to execute arbitrary code via untrusted JavaScript. Note that this is only exploitable in cases where Hermes is used to execute untrusted JavaScript. Hence, most React Native applications are not affected. | ||||
| CVE-2025-21632 | 2025-01-20 | 4.4 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Ensure shadow stack is active before "getting" registers The x86 shadow stack support has its own set of registers. Those registers are XSAVE-managed, but they are "supervisor state components" which means that userspace can not touch them with XSAVE/XRSTOR. It also means that they are not accessible from the existing ptrace ABI for XSAVE state. Thus, there is a new ptrace get/set interface for it. The regset code that ptrace uses provides an ->active() handler in addition to the get/set ones. For shadow stack this ->active() handler verifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in the thread struct. The ->active() handler is checked from some call sites of the regset get/set handlers, but not the ptrace ones. This was not understood when shadow stack support was put in place. As a result, both the set/get handlers can be called with XFEATURE_CET_USER in its init state, which would cause get_xsave_addr() to return NULL and trigger a WARN_ON(). The ssp_set() handler luckily has an ssp_active() check to avoid surprising the kernel with shadow stack behavior when the kernel is not ready for it (ARCH_SHSTK_SHSTK==0). That check just happened to avoid the warning. But the ->get() side wasn't so lucky. It can be called with shadow stacks disabled, triggering the warning in practice, as reported by Christina Schimpe: WARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0 [...] Call Trace: <TASK> ? show_regs+0x6e/0x80 ? ssp_get+0x89/0xa0 ? __warn+0x91/0x150 ? ssp_get+0x89/0xa0 ? report_bug+0x19d/0x1b0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x1d/0x80 ? asm_exc_invalid_op+0x1f/0x30 ? __pfx_ssp_get+0x10/0x10 ? ssp_get+0x89/0xa0 ? ssp_get+0x52/0xa0 __regset_get+0xad/0xf0 copy_regset_to_user+0x52/0xc0 ptrace_regset+0x119/0x140 ptrace_request+0x13c/0x850 ? wait_task_inactive+0x142/0x1d0 ? do_syscall_64+0x6d/0x90 arch_ptrace+0x102/0x300 [...] Ensure that shadow stacks are active in a thread before looking them up in the XSAVE buffer. Since ARCH_SHSTK_SHSTK and user_ssp[SHSTK_EN] are set at the same time, the active check ensures that there will be something to find in the XSAVE buffer. [ dhansen: changelog/subject tweaks ] | ||||
| CVE-2024-56717 | 1 Linux | 1 Linux Kernel | 2025-01-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: mscc: ocelot: fix incorrect IFH SRC_PORT field in ocelot_ifh_set_basic() Packets injected by the CPU should have a SRC_PORT field equal to the CPU port module index in the Analyzer block (ocelot->num_phys_ports). The blamed commit copied the ocelot_ifh_set_basic() call incorrectly from ocelot_xmit_common() in net/dsa/tag_ocelot.c. Instead of calling with "x", it calls with BIT_ULL(x), but the field is not a port mask, but rather a single port index. [ side note: this is the technical debt of code duplication :( ] The error used to be silent and doesn't appear to have other user-visible manifestations, but with new changes in the packing library, it now fails loudly as follows: ------------[ cut here ]------------ Cannot store 0x40 inside bits 46-43 - will truncate sja1105 spi2.0: xmit timed out WARNING: CPU: 1 PID: 102 at lib/packing.c:98 __pack+0x90/0x198 sja1105 spi2.0: timed out polling for tstamp CPU: 1 UID: 0 PID: 102 Comm: felix_xmit Tainted: G W N 6.13.0-rc1-00372-gf706b85d972d-dirty #2605 Call trace: __pack+0x90/0x198 (P) __pack+0x90/0x198 (L) packing+0x78/0x98 ocelot_ifh_set_basic+0x260/0x368 ocelot_port_inject_frame+0xa8/0x250 felix_port_deferred_xmit+0x14c/0x258 kthread_worker_fn+0x134/0x350 kthread+0x114/0x138 The code path pertains to the ocelot switchdev driver and to the felix secondary DSA tag protocol, ocelot-8021q. Here seen with ocelot-8021q. The messenger (packing) is not really to blame, so fix the original commit instead. | ||||
| CVE-2024-56671 | 1 Linux | 1 Linux Kernel | 2025-01-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: gpio: graniterapids: Fix vGPIO driver crash Move setting irq_chip.name from probe() function to the initialization of "irq_chip" struct in order to fix vGPIO driver crash during bootup. Crash was caused by unauthorized modification of irq_chip.name field where irq_chip struct was initialized as const. This behavior is a consequence of suboptimal implementation of gpio_irq_chip_set_chip(), which should be changed to avoid casting away const qualifier. Crash log: BUG: unable to handle page fault for address: ffffffffc0ba81c0 /#PF: supervisor write access in kernel mode /#PF: error_code(0x0003) - permissions violation CPU: 33 UID: 0 PID: 1075 Comm: systemd-udevd Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 #1 Hardware name: Intel Corporation Kaseyville RP/Kaseyville RP, BIOS KVLDCRB1.PGS.0026.D73.2410081258 10/08/2024 RIP: 0010:gnr_gpio_probe+0x171/0x220 [gpio_graniterapids] | ||||