Export limit exceeded: 361045 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (23011 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-2304 | 3 Debian, Fedoraproject, Vim | 3 Debian Linux, Fedora, Vim | 2025-11-03 | 7.8 High |
| Stack-based Buffer Overflow in GitHub repository vim/vim prior to 9.0. | ||||
| CVE-2022-1942 | 4 Apple, Debian, Fedoraproject and 1 more | 4 Macos, Debian Linux, Fedora and 1 more | 2025-11-03 | 7.8 High |
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2. | ||||
| CVE-2022-0572 | 4 Apple, Debian, Fedoraproject and 1 more | 4 Macos, Debian Linux, Fedora and 1 more | 2025-11-03 | 7.8 High |
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2. | ||||
| CVE-2022-0417 | 3 Debian, Fedoraproject, Vim | 3 Debian Linux, Fedora, Vim | 2025-11-03 | 7.8 High |
| Heap-based Buffer Overflow GitHub repository vim/vim prior to 8.2. | ||||
| CVE-2022-0392 | 4 Apple, Debian, Redhat and 1 more | 4 Macos, Debian Linux, Enterprise Linux and 1 more | 2025-11-03 | 7.8 High |
| Heap-based Buffer Overflow in GitHub repository vim prior to 8.2. | ||||
| CVE-2022-0361 | 4 Apple, Debian, Redhat and 1 more | 4 Macos, Debian Linux, Enterprise Linux and 1 more | 2025-11-03 | 7.8 High |
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2. | ||||
| CVE-2022-0359 | 4 Apple, Debian, Redhat and 1 more | 4 Macos, Debian Linux, Enterprise Linux and 1 more | 2025-11-03 | 7.8 High |
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2. | ||||
| CVE-2022-0261 | 4 Apple, Debian, Redhat and 1 more | 5 Mac Os X, Macos, Debian Linux and 2 more | 2025-11-03 | 7.8 High |
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2. | ||||
| CVE-2021-42374 | 3 Busybox, Fedoraproject, Netapp | 19 Busybox, Fedora, Cloud Backup and 16 more | 2025-11-03 | 5.3 Medium |
| An out-of-bounds heap read in Busybox's unlzma applet leads to information leak and denial of service when crafted LZMA-compressed input is decompressed. This can be triggered by any applet/format that | ||||
| CVE-2021-3872 | 4 Debian, Fedoraproject, Redhat and 1 more | 4 Debian Linux, Fedora, Enterprise Linux and 1 more | 2025-11-03 | 7.8 High |
| vim is vulnerable to Heap-based Buffer Overflow | ||||
| CVE-2021-33644 | 4 Fedoraproject, Feep, Openatom and 1 more | 4 Fedora, Libtar, Openeuler and 1 more | 2025-11-03 | 8.1 High |
| An attacker who submits a crafted tar file with size in header struct being 0 may be able to trigger an calling of malloc(0) for a variable gnu_longname, causing an out-of-bounds read. | ||||
| CVE-2025-49133 | 1 Libtpms Project | 1 Libtpms | 2025-11-03 | 5.9 Medium |
| Libtpms is a library that targets the integration of TPM functionality into hypervisors, primarily into Qemu. Libtpms, which is derived from the TPM 2.0 reference implementation code published by the Trusted Computing Group, is prone to a potential out of bounds (OOB) read vulnerability. The vulnerability occurs in the ‘CryptHmacSign’ function with an inconsistent pairing of the signKey and signScheme parameters, where the signKey is ALG_KEYEDHASH key and inScheme is an ECC or RSA scheme. The reported vulnerability is in the ‘CryptHmacSign’ function, which is defined in the "Part 4: Supporting Routines – Code" document, section "7.151 - /tpm/src/crypt/CryptUtil.c ". This vulnerability can be triggered from user-mode applications by sending malicious commands to a TPM 2.0/vTPM (swtpm) whose firmware is based on an affected TCG reference implementation. The effect on libtpms is that it will cause an abort due to the detection of the out-of-bounds access, thus for example making a vTPM (swtpm) unavailable to a VM. This vulnerability is fixed in 0.7.12, 0.8.10, 0.9.7, and 0.10.1. | ||||
| CVE-2025-47152 | 1 Pdf-xchange | 1 Pdf-xchange Editor | 2025-11-03 | 6.5 Medium |
| An out-of-bounds read vulnerability exists in the EMF functionality of PDF-XChange Co. Ltd PDF-XChange Editor 10.6.0.396. By using a specially crafted EMF file, an attacker could exploit this vulnerability to perform an out-of-bounds read, potentially leading to the disclosure of sensitive information. | ||||
| CVE-2025-43964 | 1 Libraw | 1 Libraw | 2025-11-03 | 2.9 Low |
| In LibRaw before 0.21.4, tag 0x412 processing in phase_one_correct in decoders/load_mfbacks.cpp does not enforce minimum w0 and w1 values. | ||||
| CVE-2025-43963 | 1 Libraw | 1 Libraw | 2025-11-03 | 2.9 Low |
| In LibRaw before 0.21.4, phase_one_correct in decoders/load_mfbacks.cpp allows out-of-buffer access because split_col and split_row values are not checked in 0x041f tag processing. | ||||
| CVE-2025-43962 | 1 Libraw | 1 Libraw | 2025-11-03 | 2.9 Low |
| In LibRaw before 0.21.4, phase_one_correct in decoders/load_mfbacks.cpp has out-of-bounds reads for tag 0x412 processing, related to large w0 or w1 values or the frac and mult calculations. | ||||
| CVE-2025-43961 | 1 Libraw | 1 Libraw | 2025-11-03 | 2.9 Low |
| In LibRaw before 0.21.4, metadata/tiff.cpp has an out-of-bounds read in the Fujifilm 0xf00c tag parser. | ||||
| CVE-2025-39735 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: jfs: fix slab-out-of-bounds read in ea_get() During the "size_check" label in ea_get(), the code checks if the extended attribute list (xattr) size matches ea_size. If not, it logs "ea_get: invalid extended attribute" and calls print_hex_dump(). Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds INT_MAX (2,147,483,647). Then ea_size is clamped: int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328). The "size" is then passed to print_hex_dump() (called "len" in print_hex_dump()), it is passed as type size_t (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hex_dump_to_buffer(). In print_hex_dump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hex_dump_to_buffer() on each iteration: for (i = 0; i < len; i += rowsize) { linelen = min(remaining, rowsize); remaining -= rowsize; hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize, linebuf, sizeof(linebuf), ascii); ... } The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hex_dump_to_buffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hex_dump_to_buffer() in the following for loop: for (j = 0; j < len; j++) { if (linebuflen < lx + 2) goto overflow2; ch = ptr[j]; ... } To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" before it is utilised. | ||||
| CVE-2025-39728 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: clk: samsung: Fix UBSAN panic in samsung_clk_init() With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to dereferencing `ctx->clk_data.hws` before setting `ctx->clk_data.num = nr_clks`. Move that up to fix the crash. UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP <snip> Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ... | ||||
| CVE-2025-37803 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: udmabuf: fix a buf size overflow issue during udmabuf creation by casting size_limit_mb to u64 when calculate pglimit. | ||||