Export limit exceeded: 423988 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 423988 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (4612 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-71393 | 1 Gnu | 1 Emacs | 2026-10-24 | 7.8 High |
| GNU Emacs for Android is vulnerable to an integer overflow in sfnt_read_name_table() in src/sfnt.c. The function computes an allocation size using a 32-bit length value from a TrueType font file without overflow checking. On 32-bit targets, a crafted font causes the calculation to wrap, resulting in an undersized heap allocation. A subsequent read() call writes beyond the buffer, causing a heap buffer overflow. An attacker can deliver a malicious font file via email, EWW (Emacs Web Wowser), or documents with custom faces, causing Emacs to load it. This can lead to heap memory corruption and potential code execution. This issue was fixed in commit d51a4722316efe0960994d371e1859099894d1ca | ||||
| CVE-2026-88186 | 1 Microsoft | 11 365 Apps, Microsoft 365, Microsoft Office Ltsc 2021 and 8 more | 2026-10-24 | 8.8 High |
| Heap-based buffer overflow in Microsoft Office Word allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-88088 | 1 Microsoft | 7 Microsoft Sql Server 2019 For X64-based Systems \(cu32\), Microsoft Sql Server 2022 For X64-based Systems \(cu27\), Microsoft Sql Server 2025 For X64-based Systems (gdr) and 4 more | 2026-10-24 | 7 High |
| Integer overflow or wraparound in SQL Server allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-98829 | 1 Linux | 1 Linux Kernel | 2026-10-24 | 6.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: drop oversized fragments to avoid extra_len overflow In ieee80211_rx_h_defragment(), fragment payloads are accumulated into entry->extra_len as subsequent fragments arrive: entry->extra_len += rx->skb->len; When the final fragment arrives, the head fragment is dequeued, and pskb_expand_head() is called with entry->extra_len to ensure sufficient tailroom for all queued fragments before copying: if (skb_tailroom(rx->skb) < entry->extra_len) { if (unlikely(pskb_expand_head(rx->skb, 0, entry->extra_len, GFP_ATOMIC))) { ... } } while ((skb = __skb_dequeue(&entry->skb_list))) { skb_put_data(rx->skb, skb->data, skb->len); dev_kfree_skb(skb); } In commit 69f132236827 ("mac80211: shrink struct ieee80211_fragment_entry"), entry->extra_len was narrowed from unsigned int to u16 in order to reduce structure memory footprint. However, an IEEE 802.11 frame sequence can contain up to 16 fragments (frag numbers 0..15). If a sequence of large fragments arrives (e.g. from a malicious peer or rogue AP), the sum of fragment lengths can exceed 65535 bytes (for example, 15 fragments of 4400 bytes total 66000 bytes). Because extra_len is a u16, this addition overflows and wraps around modulo 65536 (e.g. 66000 wraps to 464). Consequently, pskb_expand_head() allocates only the truncated amount of tailroom (or is skipped entirely if the head fragment already has >= 464 bytes of tailroom). When skb_put_data() subsequently iterates through the queued skb list, it appends the full payload into the undersized buffer, causing skb_put() to trigger skb_over_panic() and crash the kernel in softirq context. A legitimate MSDU in IEEE 802.11 is at most 2304 bytes (or up to 7935/11454 bytes for A-MSDU, which is not fragmented), well below U16_MAX. Fix this without increasing the size of struct ieee80211_fragment_entry by checking whether adding the incoming fragment length would exceed U16_MAX. If so, purge the queued fragments and drop the frame. [assign a separate drop reason] | ||||
| CVE-2026-69354 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-10-23 | 7.8 High |
| Heap-based buffer overflow in Windows Error Reporting allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-69521 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-10-23 | 8.8 High |
| Integer overflow or wraparound in Windows iSCSI allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2025-14181 | 3 Php, Php Group, Redhat | 3 Php, Php, Hummingbird | 2026-10-23 | 6.5 Medium |
| The SOAP HTTP client guards its response buffer growth with a check that relies on signed integer overflow, which is undefined behaviour and is not guaranteed to trigger. When the check is optimised away, a malicious SOAP server can make the client allocate a buffer far smaller than the data it then writes into it, producing a heap buffer overflow. | ||||
| CVE-2026-57488 | 2 Pupnp, Pupnp Project | 2 Pupnp, Pupnp | 2026-10-23 | 7.1 High |
| pupnp is an SDK for development of UPnP device and control point applications. Prior to 2.0.2, raw_to_int in upnp/src/genlib/net/http/httpparser.c parses Content-Length with strtol and casts the resulting long to a 32-bit int before the caller stores it as unsigned int. On LP64 systems, values greater than INT_MAX can truncate or wrap, so the HTTP parser can accept a body length different from the declared value. A remote adjacent-network peer can use the resulting parser disagreement to leave bytes to be interpreted as another request in persistent or proxied contexts, or can make a worker wait for an extremely large body and cause denial of service. This issue is fixed in 2.0.2. | ||||
| CVE-2026-6103 | 3 Php, Php Group, Redhat | 3 Php, Php, Hummingbird | 2026-10-23 | 4.3 Medium |
| phar_tar_number() parses the octal size field of a TAR header into a uint32_t with no overflow check. The field is 11 octal digits wide and holds values up to 0x1FFFFFFFF, so a size above 0xFFFFFFFF silently wraps. The parser then skips the wrong number of data blocks and interprets attacker-controlled file content as the next TAR header, which lets a crafted archive inject entries that PharData reports and extracts as if they were genuine. | ||||
| CVE-2026-23085 | 1 Linux | 1 Linux Kernel | 2026-10-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Avoid truncating memory addresses On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest. | ||||
| CVE-2026-63926 | 1 Linux | 1 Linux Kernel | 2026-10-23 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: sockmap: fix tail fragment offset in bpf_msg_push_data When bpf_msg_push_data() inserts data in the middle of a scatterlist entry, it splits the original entry into a left fragment and a right fragment. The right fragment offset is page-local, but the code advances it with `start`, which is the message-global insertion point. For inserts into a non-first SG entry, this over-advances the offset and leaves the split layout inconsistent. Advance the right fragment offset by the fragment-local delta, `start - offset`, which matches the length removed from the front of the original entry. | ||||
| CVE-2026-53329 | 1 Linux | 1 Linux Kernel | 2026-10-23 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as "capacity * vector->struct_size" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707) | ||||
| CVE-2025-66969 | 2026-10-22 | 7.5 High | ||
| Integer overflow in OpenModSim (<=1.11.0), leading to denial of service | ||||
| CVE-2026-92157 | 1 Nasa | 1 Fprime | 2026-10-22 | 6.5 Medium |
| F´ (F Prime) is a framework that enables development and deployment of spaceflight and other embedded software applications. Prior to 4.3.0, Svc::FileDownlink SendPartial range validation is vulnerable because unchecked startOffset plus length arithmetic bypasses the range check and stores a wrapped m_endOffset that is inconsistent with m_byteOffset. When an existing source file is larger than a valid startOffset and a SendPartial command supplies a length whose U32 sum with that offset wraps below the file size, under standard F Prime assertion handling, the first data-packet transition reaches FW_ASSERT and aborts or resets the process, causing denial of service. This issue is fixed in version 4.3.0. | ||||
| CVE-2026-92154 | 1 Nasa | 1 Fprime | 2026-10-22 | 8.1 High |
| F´ (F Prime) is a framework that enables development and deployment of spaceflight and other embedded software applications. Prior to 4.2.0, Svc::FileUplink handleDataPacket offset and size validation is vulnerable because the component checks byteOffset plus dataSize with wrapping U32 arithmetic and then seeks to the large attacker-controlled offset before writing. When a file-uplink DATA packet supplies a byteOffset and dataSize whose unsigned sum wraps below the declared file size, data can be written beyond the declared upload size, causing file integrity loss and potentially large sparse-file growth or resource exhaustion. This issue is fixed in version 4.2.0. | ||||
| CVE-2026-92160 | 1 Nasa | 1 Fprime | 2026-10-22 | 6.5 Medium |
| F´ (F Prime) is a framework that enables development and deployment of spaceflight and other embedded software applications. Prior to 4.3.0, Svc::FileDownlink SendPartial range validation is vulnerable because the wrapping sum bypasses file-range validation, becomes m_endOffset, and leaves m_byteOffset greater than the wrapped end offset. When an existing source file is larger than the supplied startOffset and a caller able to issue SendPartial supplies a length whose U32 sum with that offset wraps, the first data-packet send reaches FW_ASSERT and aborts or resets the process, causing denial of service. This issue is fixed in version 4.3.0. | ||||
| CVE-2026-96914 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2026-10-22 | 8.8 High |
| Integer overflow or wraparound in Windows Virtualization-Based Security (VBS) Enclave allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-83661 | 3 Adobe, Apple, Microsoft | 3 Photoshop, Macos, Windows | 2026-10-22 | 7.8 High |
| Photoshop Desktop is affected by an Integer Overflow or Wraparound vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-95636 | 3 Adobe, Apple, Microsoft | 3 Photoshop, Macos, Windows | 2026-10-22 | 7.8 High |
| Photoshop Desktop is affected by an Integer Overflow or Wraparound vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-98127 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: smb/client: validate new EOF for insert range smb3_insert_range() does not check if the new file size (i_size + len) is valid. This allows FALLOC_FL_INSERT_RANGE to bypass RLIMIT_FSIZE, exceed s_maxbytes, or produce a size outside the loff_t range. Use check_add_overflow() to calculate the new EOF. Validate it with inode_newsize_ok() before modifying the file. Reproducer, using a file on a CIFS mount: bash -c ' FILE=/mnt/cifs/repro trap "" SIGXFSZ ulimit -f 3072 # RLIMIT_FSIZE = 3 MiB # A regular write is stopped at 3 MiB. dd if=/dev/zero of="$FILE" bs=1M count=4 status=none stat -c "size after write: %s" "$FILE" # Insert 2 MiB into a 2 MiB file. truncate -s 2M "$FILE" fallocate -i -o 0 -l 2M "$FILE" stat -c "size after insert: %s" "$FILE" ' Before this change, the regular write stops at the 3 MiB limit, but insert range grows the file to 4 MiB: dd: error writing '/mnt/cifs/repro': File too large size after write: 3145728 size after insert: 4194304 After this change, insert range also fails at the limit and leaves the 2 MiB file unchanged: dd: error writing '/mnt/cifs/repro': File too large size after write: 3145728 fallocate: fallocate failed: File too large size after insert: 2097152 | ||||