Export limit exceeded: 33204 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (33204 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2016-0055 | 1 Microsoft | 1 Office | 2026-10-15 | N/A |
| Microsoft Office 2007 SP3 allows remote attackers to execute arbitrary code via a crafted Office document, aka "Microsoft Office Memory Corruption Vulnerability." | ||||
| CVE-2016-0035 | 1 Microsoft | 4 Excel, Excel For Mac, Excel Viewer and 1 more | 2026-10-15 | N/A |
| Microsoft Excel 2007 SP3, Excel 2010 SP2, Excel 2013 SP1, Excel 2013 RT SP1, Excel 2016, Excel for Mac 2011, Excel 2016 for Mac, Office Compatibility Pack SP3, and Excel Viewer allow remote attackers to execute arbitrary code via a crafted Office document, aka "Microsoft Office Memory Corruption Vulnerability." | ||||
| CVE-2026-70291 | 1 Microsoft | 7 365 Apps, Microsoft 365, Office 2021 and 4 more | 2026-10-15 | 9.8 Critical |
| Heap-based buffer overflow in Microsoft Office Outlook allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-97016 | 1 Microsoft | 3 365 Apps, Office 2021, Office 2024 | 2026-10-15 | 9.8 Critical |
| Heap-based buffer overflow in Microsoft Office Outlook allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-105593 | 1 Microsoft | 3 365 Apps, Office 2021, Office 2024 | 2026-10-15 | 8.8 High |
| Heap-based buffer overflow in Microsoft Office Access allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-105595 | 1 Microsoft | 3 365 Apps, Office 2021, Office 2024 | 2026-10-15 | 8.8 High |
| Out-of-bounds read in Microsoft Office Access allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-105596 | 1 Microsoft | 3 365 Apps, Office 2021, Office 2024 | 2026-10-15 | 8.8 High |
| Heap-based buffer overflow in Microsoft Office Access allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-105597 | 1 Microsoft | 3 365 Apps, Office 2021, Office 2024 | 2026-10-15 | 8.8 High |
| Heap-based buffer overflow in Microsoft Office Access allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-105598 | 1 Microsoft | 3 365 Apps, Office 2021, Office 2024 | 2026-10-15 | 8.8 High |
| Heap-based buffer overflow in Microsoft Office Access allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-105716 | 1 Microsoft | 3 365 Apps, Office 2021, Office 2024 | 2026-10-15 | 8.8 High |
| Heap-based buffer overflow in Microsoft Office Access allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-105717 | 1 Microsoft | 6 365 Apps, Microsoft 365 Apps For Enterprise, Microsoft Office Ltsc 2021 and 3 more | 2026-10-15 | 8.8 High |
| Heap-based buffer overflow in Microsoft Office Access allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2016-0010 | 1 Microsoft | 5 Excel For Mac, Office, Powerpoint For Mac and 2 more | 2026-10-15 | N/A |
| Microsoft Office 2007 SP3, Office 2010 SP2, Office 2013 SP1, Office 2013 RT SP1, Office 2016, Excel for Mac 2011, PowerPoint for Mac 2011, Word for Mac 2011, Excel 2016 for Mac, PowerPoint 2016 for Mac, Word 2016 for Mac, and Word Viewer allow remote attackers to execute arbitrary code via a crafted Office document, aka "Microsoft Office Memory Corruption Vulnerability." | ||||
| CVE-2026-53362 | 2 Linux, Siemens | 3 Linux Kernel, Simatic S7-1500 Tm Mfp, Simatic S7-1500 Tm Mfp Firmware | 2026-10-15 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check. | ||||
| CVE-2026-108400 | 1 Microsoft | 4 Hevc Video Extensions, Hevc Video Extensions For Licensed Applications, Hevc Video Extensions For Licensed Appplications and 1 more | 2026-10-15 | 8.8 High |
| Integer overflow or wraparound in Microsoft Windows Codecs Library allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-90082 | 1 Linux | 1 Linux Kernel | 2026-10-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: mana: Cap MSI-X vectors to the device MSI-X table size mana_gd_query_max_resources() sizes gc->num_msix_usable from resp.max_msix and the CPU count, but never from the device MSI-X table. On a 1792 vCPU M-series VM that yields 1793 while the table has 1024 entries, and mana_gd_setup_remaining_irqs() then walks indices 1..1792, running off the end of the region mapped by msix_map_region(): BUG: unable to handle page fault for address: ff8e347f8b99800c RIP: 0010:msix_prepare_msi_desc+0x7a/0x90 RAX: 0000000000004000 RBX: ff4330cb164ea780 RCX: ff8e347f8b998000 Call Trace: <TASK> __msi_domain_alloc_irqs+0x13a/0x440 msi_domain_alloc_irq_at+0x149/0x1b0 mana_gd_setup+0x351/0x890 mana_gd_probe+0x274/0x390 </TASK> RAX is index 1024 * PCI_MSIX_ENTRY_SIZE, one entry past the table. msi_insert_desc() does range check the index, but only against the MSI domain hwsize, which matches the table only for devices on an MSI parent domain. With a global PCI/MSI domain hwsize is MSI_XA_DOMAIN_SIZE, so nothing bounds the request. Cap num_msix_usable with pci_msix_vec_count(). | ||||
| CVE-2026-89568 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: kho: fix size calculation in kho_preserved_memory_reserve() kho_preserved_memory_reserve() calculates the size of a preservation by doing 1 << (order + PAGE_SHIFT). Since the '1' is a 32-bit integer, it can only be shifted by 31. That is, it will only work for preservations up to 2 GiB. Larger preservations will trigger undefined behaviour. While preservations larger than 2 GiB can't be obtained via folios currently, they can be obtained via kho_preserve_pages(). For example, memblock reserve_mem uses kho_preserve_pages(). Reservations larger than 2 GiB are valid and will trigger this bug if properly aligned. Fix it by using 1UL for shifting. | ||||
| CVE-2026-74336 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: bound S1G TIM PVB walk to the TIM element ieee80211_s1g_check_tim() parses the S1G Partial Virtual Bitmap (PVB) of a received TIM element. The TIM is handed in as the element payload: ieee802_11_parse_elems_full() stores elems->tim = elem->data and elems->tim_len = elem->datalen (net/mac80211/parse.c), so the valid bytes are [tim, tim + tim_len). When walking the encoded blocks the function passes the walker an end sentinel of (const u8 *)tim + tim_len + 2, i.e. two bytes past the end of the element. ieee80211_s1g_find_target_block() loops while (ptr + 1 <= end) and dereferences ptr (and the per-mode ieee80211_s1g_len_*() helpers read *ptr), so it can read up to two bytes beyond the TIM element -- an out-of-bounds read of adjacent skb/heap data when the TIM is the last element in the frame. The +2 appears to account for the element id/len header, but tim already points past that header at the element payload, so the addend is wrong. Pass the correct element end, (const u8 *)tim + tim_len. | ||||
| CVE-2026-77902 | 1 Microsoft | 8 365 Apps, Microsoft 365, Microsoft Office 365 For Mac and 5 more | 2026-10-15 | 8.8 High |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-96940 | 1 Microsoft | 9 Exchange Server, Exchange Server 2016, Exchange Server 2019 and 6 more | 2026-10-15 | 8.8 High |
| Weak authentication in Microsoft Exchange Server allows an authorized attacker to elevate privileges over a network. | ||||
| CVE-2026-53198 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which "goto out"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time. | ||||