Export limit exceeded: 354383 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (3684 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-27940 | 1 Ggml | 1 Llama.cpp | 2026-04-28 | 7.8 High |
| llama.cpp is an inference of several LLM models in C/C++. Prior to b8146, the gguf_init_from_file_impl() in gguf.cpp is vulnerable to an Integer overflow, leading to an undersized heap allocation. Using the subsequent fread() writes 528+ bytes of attacker-controlled data past the buffer boundary. This is a bypass of a similar bug in the same file - CVE-2025-53630, but the fix overlooked some areas. This vulnerability is fixed in b8146. | ||||
| CVE-2026-25208 | 2 Samsung, Samsung Open Source | 2 Escargot, Escargot | 2026-04-28 | 8.1 High |
| Integer overflow vulnerability in Samsung Open Source Escargot allows Overflow Buffers.This issue affects Escargot: 97e8115ab1110bc502b4b5e4a0c689a71520d335. | ||||
| CVE-2026-31525 | 1 Linux | 1 Linux Kernel | 2026-04-28 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix undefined behavior in interpreter sdiv/smod for INT_MIN The BPF interpreter's signed 32-bit division and modulo handlers use the kernel abs() macro on s32 operands. The abs() macro documentation (include/linux/math.h) explicitly states the result is undefined when the input is the type minimum. When DST contains S32_MIN (0x80000000), abs((s32)DST) triggers undefined behavior and returns S32_MIN unchanged on arm64/x86. This value is then sign-extended to u64 as 0xFFFFFFFF80000000, causing do_div() to compute the wrong result. The verifier's abstract interpretation (scalar32_min_max_sdiv) computes the mathematically correct result for range tracking, creating a verifier/interpreter mismatch that can be exploited for out-of-bounds map value access. Introduce abs_s32() which handles S32_MIN correctly by casting to u32 before negating, avoiding signed overflow entirely. Replace all 8 abs((s32)...) call sites in the interpreter's sdiv32/smod32 handlers. s32 is the only affected case -- the s64 division/modulo handlers do not use abs(). | ||||
| CVE-2026-31590 | 1 Linux | 1 Linux Kernel | 2026-04-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range); Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both "addr" and "size" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater than ULONG_MAX. That wart will be cleaned up in the near future. if (range->addr > ULONG_MAX || range->size > ULONG_MAX) return -EINVAL; Opportunistically add a comment to explain why the code calculates the number of pages the "hard" way, e.g. instead of just shifting @ulen. | ||||
| CVE-2026-41602 | 1 Apache | 1 Thrift | 2026-04-28 | 7.5 High |
| Integer Overflow or Wraparound vulnerability in Apache Thrift TFramedTransport Go language implementation This issue affects Apache Thrift: before 0.23.0. Users are recommended to upgrade to version 0.23.0, which fixes the issue. | ||||
| CVE-2026-41605 | 1 Apache | 1 Thrift | 2026-04-28 | 7.3 High |
| Integer Overflow or Wraparound vulnerability in Apache Thrift. This issue affects Apache Thrift: before 0.23.0. Users are recommended to upgrade to version 0.23.0, which fixes the issue. | ||||
| CVE-2026-33666 | 2 Nds-association, Ndsev | 2 Zserio, Zserio | 2026-04-28 | 7.5 High |
| Zserio is a framework for serializing structured data with a compact and efficient way with low overhead. Prior to 2.18.1, in BitStreamReader.h readBytes() / readString(), the setBitPosition() bounds check receives the overflowed value and is completely bypassed. The code then reads len bytes (512 MB) from a buffer that is only a few bytes long, causing a segmentation fault. This vulnerability is fixed in 2.18.1. | ||||
| CVE-2026-41416 | 2 Pjsip, Teluu | 2 Pjproject, Pjsip | 2026-04-28 | 7.5 High |
| PJSIP is a free and open source multimedia communication library written in C. In 2.16 and earlier, there is an integer overflow in media stream buffer size calculation when processing SDP with asymmetric ptime configuration. The overflow may result in an undersized buffer allocation, which can lead to unexpected application termination or memory corruption This vulnerability is fixed in 2.17. | ||||
| CVE-2026-40915 | 2 Gimp, Redhat | 2 Gimp, Enterprise Linux | 2026-04-28 | 5.5 Medium |
| A flaw was found in GIMP. A remote attacker could exploit an integer overflow vulnerability in the FITS image loader by providing a specially crafted FITS file. This integer overflow leads to a zero-byte memory allocation, which is then subjected to a heap buffer overflow when processing pixel data. Successful exploitation could result in a denial of service (DoS) or potentially arbitrary code execution. | ||||
| CVE-2018-17958 | 4 Canonical, Debian, Qemu and 1 more | 8 Ubuntu Linux, Debian Linux, Qemu and 5 more | 2026-04-28 | 7.5 High |
| Qemu has a Buffer Overflow in rtl8139_do_receive in hw/net/rtl8139.c because an incorrect integer data type is used. | ||||
| CVE-2026-33662 | 2 Linaro, Op-tee | 2 Op-tee, Op-tee Os | 2026-04-28 | 7.5 High |
| OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. From 3.8.0 to 4.10, in the function emsa_pkcs1_v1_5_encode() in core/drivers/crypto/crypto_api/acipher/rsassa.c, the amount of padding needed, "PS size", is calculated by subtracting the size of the digest and other fields required for the EMA-PKCS1-v1_5 encoding from the size of the modulus of the key. By selecting a small enough modulus, this subtraction can overflow. The padding is added as a string of 0xFF bytes with a call to memset(), and an underflowed integer will cause the memset() call to overwrite until OP-TEE crashes. This only affects platforms registering RSA acceleration. | ||||
| CVE-2026-31491 | 1 Linux | 1 Linux Kernel | 2026-04-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Harden depth calculation functions An issue was exposed where OS can pass in U32_MAX for SQ/RQ/SRQ size. This can cause integer overflow and truncation of SQ/RQ/SRQ depth returning a success when it should have failed. Harden the functions to do all depth calculations and boundary checking in u64 sizes. | ||||
| CVE-2025-31203 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2026-04-28 | 6.5 Medium |
| An integer overflow was addressed with improved input validation. This issue is fixed in iOS 18.4 and iPadOS 18.4, iPadOS 17.7.6, macOS Sequoia 15.4, macOS Sonoma 14.7.5, tvOS 18.4, visionOS 2.4, watchOS 11.4. An attacker on the local network may be able to cause a denial-of-service. | ||||
| CVE-2025-31221 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2026-04-28 | 7.5 High |
| An integer overflow was addressed with improved input validation. This issue is fixed in iOS 18.5 and iPadOS 18.5, iPadOS 17.7.7, macOS Sequoia 15.5, macOS Sonoma 14.7.6, macOS Ventura 13.7.6, tvOS 18.5, visionOS 2.5, watchOS 11.5. A remote attacker may be able to leak memory. | ||||
| CVE-2025-24156 | 1 Apple | 1 Macos | 2026-04-28 | 8.8 High |
| An integer overflow was addressed through improved input validation. This issue is fixed in macOS Sequoia 15.3, macOS Sonoma 14.7.3, macOS Ventura 13.7.3. An app may be able to elevate privileges. | ||||
| CVE-2025-46285 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2026-04-27 | 7.8 High |
| An integer overflow was addressed by adopting 64-bit timestamps. This issue is fixed in iOS 18.7.3 and iPadOS 18.7.3, iOS 26.2 and iPadOS 26.2, macOS Sequoia 15.7.3, macOS Sonoma 14.8.3, macOS Tahoe 26.2, tvOS 26.2, visionOS 26.2, watchOS 26.2. An app may be able to gain root privileges. | ||||
| CVE-2026-31633 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix integer overflow in rxgk_verify_response() In rxgk_verify_response(), there's a potential integer overflow due to rounding up token_len before checking it, thereby allowing the length check to be bypassed. Fix this by checking the unrounded value against len too (len is limited as the response must fit in a single UDP packet). | ||||
| CVE-2026-31641 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix RxGK token loading to check bounds rxrpc_preparse_xdr_yfs_rxgk() reads the raw key length and ticket length from the XDR token as u32 values and passes each through round_up(x, 4) before using the rounded value for validation and allocation. When the raw length is >= 0xfffffffd, round_up() wraps to 0, so the bounds check and kzalloc both use 0 while the subsequent memcpy still copies the original ~4 GiB value, producing a heap buffer overflow reachable from an unprivileged add_key() call. Fix this by: (1) Rejecting raw key lengths above AFSTOKEN_GK_KEY_MAX and raw ticket lengths above AFSTOKEN_GK_TOKEN_MAX before rounding, consistent with the caps that the RxKAD path already enforces via AFSTOKEN_RK_TIX_MAX. (2) Sizing the flexible-array allocation from the validated raw key length via struct_size_t() instead of the rounded value. (3) Caching the raw lengths so that the later field assignments and memcpy calls do not re-read from the token, eliminating a class of TOCTOU re-parse. The control path (valid token with lengths within bounds) is unaffected. | ||||
| CVE-2026-31659 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field. | ||||
| CVE-2026-31649 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a small linear portion (nopaged_len <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax * i pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward. | ||||