Export limit exceeded: 16991 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (1114 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-72074 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix type confusion in CDC union descriptor parsing The driver currently trusts the bMasterInterface0 from the CDC union descriptor without verifying that it matches the interface being probed. This could lead to the driver overwriting the private data of another interface. Validate that the control interface found in the descriptor is indeed the one we are probing. | ||||
| CVE-2026-64904 | 1 Microsoft | 8 365 Apps, Microsoft 365, Office 2019 and 5 more | 2026-08-14 | 7.8 High |
| Access of resource using incompatible type ('type confusion') in Microsoft Office allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68163 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support device-private entries") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 ("mm/huge_memory: implement device-private THP splitting") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David] | ||||
| CVE-2026-64240 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: media: rc: igorplugusb: fix control request setup packet Commit eac69475b01f ("media: rc: igorplugusb: heed coherency rules") changed the control request storage from an embedded struct to an allocated pointer so it can obey DMA coherency rules. However, the driver still passes &ir->request to usb_fill_control_urb(). That points the URB setup packet at the pointer field itself rather than at the allocated struct usb_ctrlrequest. USB core then interprets pointer bytes as the setup packet. This can produce an invalid bRequestType and trigger the control direction warning reported by syzbot: usb 2-1: BOGUS control dir, pipe 80003580 doesn't match bRequestType 0 Pass ir->request itself as the setup packet. | ||||
| CVE-2026-68803 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 7.8 High |
| Access of resource using incompatible type ('type confusion') in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68811 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 7.8 High |
| Access of resource using incompatible type ('type confusion') in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-64704 | 1 Apple | 1 Macos | 2026-08-13 | 9.8 Critical |
| A type confusion issue was addressed with improved memory handling. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6. An app may be able to cause unexpected system termination. | ||||
| CVE-2026-64727 | 1 Apple | 2 Macos, Tvos | 2026-08-13 | 9.8 Critical |
| A type confusion issue was addressed with improved memory handling. This issue is fixed in macOS Tahoe 26.6, tvOS 26.6. An app may be able to cause unexpected system termination. | ||||
| CVE-2026-68174 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:<module>' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths. | ||||
| CVE-2026-70339 | 1 Microsoft | 1 Edge Chromium | 2026-08-12 | 5.4 Medium |
| Access of resource using incompatible type ('type confusion') in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-64608 | 1 Apache | 1 Fory | 2026-08-11 | 9.8 Critical |
| Heap type confusion and out-of-bounds read/write in the Apache Fory C++ implementation. When deserializing data in compatible mode, the field-skip paths do not correctly validate the declared field types against the actual data, so input with an inconsistent schema can cause type confusion and out-of-bounds memory access. Only the C++ implementation is affected; other language implementations of Apache Fory are not. This issue affects Apache Fory C++: from 0.14.0 before 1.4.0. Users are recommended to upgrade to version 1.4.0, which fixes the issue. | ||||
| CVE-2024-21363 | 1 Microsoft | 23 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 20 more | 2026-08-10 | 7.8 High |
| Microsoft Message Queuing (MSMQ) Remote Code Execution Vulnerability | ||||
| CVE-2024-21357 | 1 Microsoft | 23 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 20 more | 2026-08-10 | 8.1 High |
| Windows Pragmatic General Multicast (PGM) Remote Code Execution Vulnerability | ||||
| CVE-2021-38658 | 1 Microsoft | 4 Office, Office 2013, Office 2016 and 1 more | 2026-08-10 | 7.8 High |
| Microsoft Office Graphics Remote Code Execution Vulnerability | ||||
| CVE-2026-71558 | 1 Apache | 1 Fory | 2026-08-07 | 9.8 Critical |
| Heap type confusion vulnerability in Apache Fory C++ deserialization. This issue affects Apache Fory C++ versions from 0.14.0 before 1.5.0. A crafted input payload can bypass type compatibility checks during polymorphic smart-pointer deserialization, causing an object of an incompatible type to be treated as the declared base type. This may result in undefined behavior and potentially lead to denial of service or arbitrary code execution. Users are recommended to upgrade to Apache Fory 1.5.0, which fixes this issue. Applications not using Apache Fory C++ polymorphic smart-pointer deserialization are not affected. | ||||
| CVE-2026-19150 | 1 Google | 1 Chrome | 2026-08-07 | 8.8 High |
| Inappropriate implementation in V8 in Google Chrome prior to 151.0.7922.109 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-15572 | 1 Redhat | 2 Build Keycloak, Build Of Keycloak | 2026-08-07 | 8.8 High |
| A flaw was found in Keycloak's Dynamic Client Registration (DCR) security policy management. The "Allowed Protocol Mapper Types" policy, which restricts which types of data mappers a client can use, fails to re-validate the mapper type during a client update if the mapper's configuration remains unchanged. An attacker with client registration privileges can exploit this by first registering an allowed mapper type with a malicious configuration and then swapping it for a restricted, high-privilege mapper type (such as one that hardcodes administrative roles). This allows the attacker to gain full administrative access to the Keycloak realm. | ||||
| CVE-2026-58541 | 1 Microsoft | 19 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 16 more | 2026-08-07 | 7.8 High |
| Access of resource using incompatible type ('type confusion') in Windows DWM allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-66321 | 1 Microsoft | 1 Edge Chromium | 2026-08-04 | 7.4 High |
| Access of resource using incompatible type ('type confusion') in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2024-56717 | 1 Linux | 1 Linux Kernel | 2026-08-04 | 7.5 High |
| 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. | ||||