Total
3831 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-36900 | 1 Microsoft | 12 Windows 10, Windows 10 1607, Windows 10 1809 and 9 more | 2026-08-10 | N/A | 7.8 HIGH |
| Windows Common Log File System Driver Elevation of Privilege Vulnerability | |||||
| CVE-2023-36866 | 1 Microsoft | 3 365 Apps, Office, Office Long Term Servicing Channel | 2026-08-10 | N/A | 7.8 HIGH |
| Microsoft Office Visio Remote Code Execution Vulnerability | |||||
| CVE-2023-35385 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2026-08-10 | N/A | 9.8 CRITICAL |
| Microsoft Message Queuing (MSMQ) Remote Code Execution Vulnerability | |||||
| CVE-2023-35383 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2026-08-10 | N/A | 7.5 HIGH |
| Microsoft Message Queuing Information Disclosure Vulnerability | |||||
| CVE-2023-35381 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2026-08-10 | N/A | 8.8 HIGH |
| Windows Fax Service Remote Code Execution Vulnerability | |||||
| CVE-2023-35372 | 1 Microsoft | 3 365 Apps, Office, Office Long Term Servicing Channel | 2026-08-10 | N/A | 7.8 HIGH |
| Microsoft Office Visio Remote Code Execution Vulnerability | |||||
| CVE-2021-34536 | 1 Microsoft | 3 Windows 10, Windows Server 2016, Windows Server 2019 | 2026-08-10 | 4.6 MEDIUM | 7.8 HIGH |
| Windows Storage Spaces Controller Elevation of Privilege Vulnerability | |||||
| CVE-2021-34513 | 1 Microsoft | 2 Windows 10, Windows Server 2016 | 2026-08-10 | 7.2 HIGH | 7.8 HIGH |
| Windows Storage Spaces Controller Elevation of Privilege Vulnerability | |||||
| CVE-2021-34512 | 1 Microsoft | 3 Windows 10, Windows Server 2016, Windows Server 2019 | 2026-08-10 | 7.2 HIGH | 7.8 HIGH |
| Windows Storage Spaces Controller Elevation of Privilege Vulnerability | |||||
| CVE-2021-34510 | 1 Microsoft | 3 Windows 10, Windows Server 2016, Windows Server 2019 | 2026-08-10 | 4.6 MEDIUM | 7.8 HIGH |
| Windows Storage Spaces Controller Elevation of Privilege Vulnerability | |||||
| CVE-2026-66757 | 2 Gimp, Redhat | 2 Gimp, Enterprise Linux | 2026-08-10 | N/A | 5.5 MEDIUM |
| A flaw was found in the file-sgi plugin in GIMP. When processing an RLE-compressed SGI image, the plugin allocates memory for a row table. The image header dimensions (ysize and zsize) are read as 16-bit unsigned integers. If a crafted file sets both dimensions to their maximum value (65535), the multiplication ysize * zsize overflows the standard 32-bit int boundary before being passed to calloc. This integer overflow issue results in undefined behavior, aborting the plugin and causing a denial of service. | |||||
| CVE-2026-3945 | 2026-08-10 | 7.8 HIGH | 7.5 HIGH | ||
| An integer overflow vulnerability in the HTTP chunked transfer encoding parser in tinyproxy up to and including version 1.11.3 allows an unauthenticated remote attacker to cause a denial of service (DoS). The issue occurs because chunk size values are parsed using strtol without properly validating overflow conditions (e.g., errno == ERANGE). | |||||
| CVE-2026-66039 | 1 Ffmpeg | 1 Ffmpeg | 2026-08-07 | N/A | 8.8 HIGH |
| FFmpeg through 8.1.2, fixed in commit aafb5c6, contains a signed integer overflow vulnerability in the MACE6 audio decoder that allows attackers to corrupt heap memory by supplying a crafted CAF file with a malicious bytes_per_packet value. Attackers can craft a CAF file with oversized bytes_per_packet and frames_per_packet values in the desc chunk to trigger an integer overflow in mace_decode_frame() during output sample count computation, resulting in an undersized buffer allocation and heap out-of-bounds write that could enable code execution. | |||||
| CVE-2021-41864 | 4 Debian, Fedoraproject, Linux and 1 more | 24 Debian Linux, Fedora, Linux Kernel and 21 more | 2026-08-05 | 4.6 MEDIUM | 7.8 HIGH |
| prealloc_elems_and_freelist in kernel/bpf/stackmap.c in the Linux kernel before 5.14.12 allows unprivileged users to trigger an eBPF multiplication integer overflow with a resultant out-of-bounds write. | |||||
| CVE-2026-8631 | 1 Hp | 1 Linux Imaging And Printing | 2026-08-04 | N/A | 9.8 CRITICAL |
| A potential security vulnerability has been identified in the HP Linux Imaging and Printing Software. This potential vulnerability may allow escalation of privileges and/or arbitrary code execution via an integer overflow in the hpcups processing path when handling crafted print data. | |||||
| CVE-2024-58010 | 1 Linux | 1 Linux Kernel | 2026-08-04 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix integer overflow bug on 32 bit systems Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The "relocs" count needs to be checked as well. Otherwise on 32bit systems the calculation of "full_data" could be wrong. full_data = data_len + relocs * sizeof(unsigned long); | |||||
| CVE-2024-56368 | 1 Linux | 1 Linux Kernel | 2026-08-04 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix overflow in __rb_map_vma An overflow occurred when performing the following calculation: nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; Add a check before the calculation to avoid this problem. syzbot reported this as a slab-out-of-bounds in __rb_map_vma: BUG: KASAN: slab-out-of-bounds in __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058 Read of size 8 at addr ffff8880767dd2b8 by task syz-executor187/5836 CPU: 0 UID: 0 PID: 5836 Comm: syz-executor187 Not tainted 6.13.0-rc2-syzkaller-00159-gf932fb9b4074 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058 ring_buffer_map+0x56e/0x9b0 kernel/trace/ring_buffer.c:7138 tracing_buffers_mmap+0xa6/0x120 kernel/trace/trace.c:8482 call_mmap include/linux/fs.h:2183 [inline] mmap_file mm/internal.h:124 [inline] __mmap_new_file_vma mm/vma.c:2291 [inline] __mmap_new_vma mm/vma.c:2355 [inline] __mmap_region+0x1786/0x2670 mm/vma.c:2456 mmap_region+0x127/0x320 mm/mmap.c:1348 do_mmap+0xc00/0xfc0 mm/mmap.c:496 vm_mmap_pgoff+0x1ba/0x360 mm/util.c:580 ksys_mmap_pgoff+0x32c/0x5c0 mm/mmap.c:542 __do_sys_mmap arch/x86/kernel/sys_x86_64.c:89 [inline] __se_sys_mmap arch/x86/kernel/sys_x86_64.c:82 [inline] __x64_sys_mmap+0x125/0x190 arch/x86/kernel/sys_x86_64.c:82 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The reproducer for this bug is: ------------------------8<------------------------- #include <fcntl.h> #include <stdlib.h> #include <unistd.h> #include <asm/types.h> #include <sys/mman.h> int main(int argc, char **argv) { int page_size = getpagesize(); int fd; void *meta; system("echo 1 > /sys/kernel/tracing/buffer_size_kb"); fd = open("/sys/kernel/tracing/per_cpu/cpu0/trace_pipe_raw", O_RDONLY); meta = mmap(NULL, page_size, PROT_READ, MAP_SHARED, fd, page_size * 5); } ------------------------>8------------------------- | |||||
| CVE-2024-53151 | 1 Linux | 1 Linux Kernel | 2026-08-04 | N/A | 7.5 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: svcrdma: Address an integer overflow Dan Carpenter reports: > Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data > structure") from Jun 22, 2020 (linux-next), leads to the following > Smatch static checker warning: > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk() > warn: potential user controlled sizeof overflow 'segcount * 4 * 4' > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c > 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt) > 489 { > 490 u32 segcount; > 491 __be32 *p; > 492 > 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount)) > ^^^^^^^^ > > 494 return false; > 495 > 496 /* A bogus segcount causes this buffer overflow check to fail. */ > 497 p = xdr_inline_decode(&rctxt->rc_stream, > --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p)); > > > segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will > have an integer overflow and some those values will be accepted by > xdr_inline_decode(). | |||||
| CVE-2024-53146 | 1 Linux | 1 Linux Kernel | 2026-08-04 | N/A | 9.1 CRITICAL |
| In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent a potential integer overflow If the tag length is >= U32_MAX - 3 then the "length + 4" addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decode_cb_compound4res() does not have to perform arithmetic on the unsafe length value. | |||||
| CVE-2024-53111 | 1 Linux | 1 Linux Kernel | 2026-08-04 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an "orig_old_start" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include <stdlib.h> #include <stdio.h> #include <err.h> #include <sys/mman.h> #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, "mmap 1"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, "mmap 2"); *p1 = 0x41; printf("first char is 0x%02hhx\n", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf("mremap() failed; first char is 0x%02hhx\n", *p1); } else { printf("mremap() succeeded; first char is 0x%02hhx\n", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ``` | |||||