Export limit exceeded: 339475 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 42196 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (42196 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-43239 | 1 Apple | 4 Macos, Macos Sequoia, Macos Sonoma and 1 more | 2025-11-03 | 7.1 High |
| An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7, macOS Ventura 13.7.7. Processing a maliciously crafted file may lead to unexpected app termination. | ||||
| CVE-2025-43226 | 1 Apple | 9 Ios, Ipados, Iphone Os and 6 more | 2025-11-03 | 4 Medium |
| An out-of-bounds read was addressed with improved input validation. This issue is fixed in watchOS 11.6, iOS 18.6 and iPadOS 18.6, iPadOS 17.7.9, tvOS 18.6, macOS Sequoia 15.6, macOS Sonoma 14.7.7, visionOS 2.6. Processing a maliciously crafted image may result in disclosure of process memory. | ||||
| CVE-2025-43221 | 1 Apple | 7 Ios, Ipados, Iphone Os and 4 more | 2025-11-03 | 7.1 High |
| An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in macOS Sequoia 15.6, iOS 18.6 and iPadOS 18.6, visionOS 2.6, tvOS 18.6. Processing a maliciously crafted media file may lead to unexpected app termination or corrupt process memory. | ||||
| CVE-2025-43218 | 1 Apple | 2 Macos, Macos Sequoia | 2025-11-03 | 5.5 Medium |
| An out-of-bounds read was addressed with improved input validation. This issue is fixed in macOS Sequoia 15.6. Processing a maliciously crafted USD file may disclose memory contents. | ||||
| CVE-2025-43186 | 1 Apple | 10 Ios, Ipados, Iphone Os and 7 more | 2025-11-03 | 9.8 Critical |
| The issue was addressed with improved memory handling. This issue is fixed in watchOS 11.6, iOS 18.6 and iPadOS 18.6, tvOS 18.6, macOS Sequoia 15.6, macOS Sonoma 14.7.7, visionOS 2.6, macOS Ventura 13.7.7. Parsing a file may lead to an unexpected app termination. | ||||
| 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. | ||||
| CVE-2025-37785 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-03 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: ext4: fix OOB read when checking dotdot dir Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed). ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e | ||||
| CVE-2025-32776 | 2025-11-03 | 5.5 Medium | ||
| OpenRazer is an open source driver and user-space daemon to control Razer device lighting and other features on GNU/Linux. By writing specially crafted data to the `matrix_custom_frame` file, an attacker can cause the custom kernel driver to read more bytes than provided by user space. This data will be written into the RGB arguments which will be sent to the USB device. This issue has been patched in v3.10.2. | ||||
| CVE-2025-32461 | 1 Tiki | 1 Tiki | 2025-11-03 | 9.9 Critical |
| wikiplugin_includetpl in lib/wiki-plugins/wikiplugin_includetpl.php in Tiki before 28.3 mishandles input to an eval. The fixed versions are 21.12, 24.8, 27.2, and 28.3. | ||||
| CVE-2025-32415 | 1 Xmlsoft | 1 Libxml2 | 2025-11-03 | 2.9 Low |
| In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used. | ||||
| CVE-2025-32365 | 1 Freedesktop | 1 Poppler | 2025-11-03 | 4 Medium |
| Poppler before 25.04.0 allows crafted input files to trigger out-of-bounds reads in the JBIG2Bitmap::combine function in JBIG2Stream.cc because of a misplaced isOk check. | ||||
| CVE-2025-32364 | 1 Freedesktop | 1 Poppler | 2025-11-03 | 4 Medium |
| A floating-point exception in the PSStack::roll function of Poppler before 25.04.0 can cause an application to crash when handling malformed inputs associated with INT_MIN. | ||||
| CVE-2025-32072 | 2025-11-03 | N/A | ||
| Improper Encoding or Escaping of Output vulnerability in The Wikimedia Foundation Mediawiki Core - Feed Utils allows WebView Injection.This issue affects Mediawiki Core - Feed Utils: from 1.39 through 1.43. | ||||
| CVE-2025-31257 | 2 Apple, Redhat | 13 Ipados, Iphone Os, Macos and 10 more | 2025-11-03 | 4.7 Medium |
| This issue was addressed with improved memory handling. This issue is fixed in watchOS 11.5, tvOS 18.5, iOS 18.5 and iPadOS 18.5, macOS Sequoia 15.5, visionOS 2.5, Safari 18.5. Processing maliciously crafted web content may lead to an unexpected Safari crash. | ||||
| CVE-2025-31234 | 1 Apple | 5 Ipados, Iphone Os, Macos and 2 more | 2025-11-03 | 8.2 High |
| The issue was addressed with improved input sanitization. This issue is fixed in visionOS 2.5, iOS 18.5 and iPadOS 18.5, macOS Sequoia 15.5, tvOS 18.5. An attacker may be able to cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2025-31221 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-11-03 | 7.5 High |
| An integer overflow was addressed with improved input validation. This issue is fixed in watchOS 11.5, macOS Sonoma 14.7.6, tvOS 18.5, iPadOS 17.7.7, iOS 18.5 and iPadOS 18.5, macOS Sequoia 15.5, visionOS 2.5, macOS Ventura 13.7.6. A remote attacker may be able to leak memory. | ||||
| CVE-2025-31219 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-11-03 | 7.1 High |
| The issue was addressed with improved memory handling. This issue is fixed in watchOS 11.5, macOS Sonoma 14.7.6, tvOS 18.5, iPadOS 17.7.7, iOS 18.5 and iPadOS 18.5, macOS Sequoia 15.5, visionOS 2.5, macOS Ventura 13.7.6. An attacker may be able to cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2025-31209 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-11-03 | 6.3 Medium |
| An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in watchOS 11.5, macOS Sonoma 14.7.6, tvOS 18.5, iPadOS 17.7.7, iOS 18.5 and iPadOS 18.5, macOS Sequoia 15.5, visionOS 2.5, macOS Ventura 13.7.6. Parsing a file may lead to disclosure of user information. | ||||