Total
14482 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-34709 | 1 Adobe | 1 Substance 3d Sampler | 2026-06-11 | 7.8 High |
| Substance3D - Sampler versions 6.0.0 and earlier are affected by an out-of-bounds write 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-2025-10238 | 1 Lenovo | 213 E14 Gen 4 (type 21e3, 21e4) Laptops (thinkpad) Bios, E14 Gen 4 Type 21e3 21e4 Laptops Thinkpad Bios, E14 Gen 5 (type 21jr, 21js) Laptop (thinkpad) Bios and 210 more | 2026-06-11 | 6.7 Medium |
| During an internal security assessment, a potential out-of-bounds write vulnerability was discovered in the BIOS of some ThinkPad products could allow a privileged local user to execute code in System Management Mode (SMM). | ||||
| CVE-2026-24193 | 1 Nvidia | 6 Geforce, Gpu Display Driver, Nvs and 3 more | 2026-06-11 | 7.8 High |
| NVIDIA Display Driver for Windows and Linux contains a vulnerability where an attacker could cause an out-of-bounds write. A successful exploit of this vulnerability might lead to denial of service, escalation of privileges, information disclosure, data tampering, and code execution. | ||||
| CVE-2026-46145 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Validate rx_hash_key_len Sashiko points out that rx_hash_key_len comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow. | ||||
| CVE-2026-46234 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: vsock: fix buffer size clamping order In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size. | ||||
| CVE-2026-46209 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check(). | ||||
| CVE-2026-3088 | 1 Netgear | 8 Rbr860, Rbre950, Rbre960 and 5 more | 2026-06-10 | N/A |
| Unauthenticated users on the local network can cause the router to become unavailable by sending specially crafted requests. | ||||
| CVE-2023-52356 | 2 Libtiff, Redhat | 6 Libtiff, Ai Inference Server, Discovery and 3 more | 2026-06-10 | 7.5 High |
| A segment fault (SEGV) flaw was found in libtiff that could be triggered by passing a crafted tiff file to the TIFFReadRGBATileExt() API. This flaw allows a remote attacker to cause a heap-buffer overflow, leading to a denial of service. | ||||
| CVE-2026-48563 | 1 Microsoft | 18 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 15 more | 2026-06-10 | 7.5 High |
| Heap-based buffer overflow in Remote Desktop Client allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-46197 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: validate SVM ioctl nattr against buffer size Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f) | ||||
| CVE-2026-11672 | 1 Google | 2 Android, Chrome | 2026-06-10 | 8.3 High |
| Heap buffer overflow in GPU in Google Chrome on Android prior to 149.0.7827.103 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-49840 | 2 Freeswitch, Signalwire | 2 Freeswitch, Freeswitch | 2026-06-10 | 9.1 Critical |
| FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. Prior to version 1.11.1, esl_recv_event() parses Content-Length with atol() and passes the result straight to malloc(len + 1) with no sign or magnitude check. A malicious or man-in-the-middle ESL peer can send a frame with a negative Content-Length to corrupt the heap of, or crash, any process linked against libesl, before the client has authenticated to that peer. This issue has been patched in version 1.11.1. | ||||
| CVE-2026-49475 | 2 Freeswitch, Signalwire | 2 Freeswitch, Freeswitch | 2026-06-10 | 7.5 High |
| FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. Prior to version 1.11.0, a STUN packet whose declared attribute length is shorter than the structure the parser casts to causes the parser to read and write past the end of the attribute, producing an out-of-bounds memory access on the per-leg media buffer. This issue has been patched in version 1.11.0. | ||||
| CVE-2026-10879 | 2 Hmbrand, Perl | 2 Dbi, Dbi | 2026-06-10 | 9.8 Critical |
| DBI versions before 1.648 for Perl have a heap overflow when preparsing SQL statements with more than 9 binders. The preparse method expands SQL placeholder characters to numbered binders of the form :pN, but only allocates three characters per binder in the buffer. Placeholders 10-99 require four characters, 100-999 require five characters, et cetera. | ||||
| CVE-2026-11645 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-06-10 | 8.8 High |
| Out of bounds read and write in V8 in Google Chrome prior to 149.0.7827.103 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-44634 | 1 Simpleble | 1 Simpleble | 2026-06-10 | N/A |
| SimpleBLE is a cross-platform library and bindings for Bluetooth Low Energy (BLE). Prior to version 0.14.0, there are multiple stack-based buffer overflow vulnerabilities in SimpleBLE. There is a stack overflow vulnerability in the dongl backend’s Protocol::simpleble_write function (local, caller-controlled input). A stack overflow vulnerability when processing manufacturer-specific data in BLE advertisements (remote, no pairing or connection required). Lastly, a stack overflow vulnerability when processing service data in BLE advertisements (remote, no pairing or connection required). This issue has been patched in version 0.14.0. | ||||
| CVE-2026-34706 | 3 Adobe, Apple, Microsoft | 3 Incopy, Macos, Windows | 2026-06-10 | 7.8 High |
| InCopy versions 21.3, 20.5.3 and earlier are affected by an out-of-bounds write 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-34700 | 3 Adobe, Apple, Microsoft | 4 Indesign, Indesign Desktop, Macos and 1 more | 2026-06-10 | 7.8 High |
| InDesign Desktop versions 21.3, 20.5.3 and earlier are affected by an out-of-bounds write 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-48293 | 1 Adobe | 1 Indesign Desktop | 2026-06-10 | 7.8 High |
| InDesign Desktop versions 21.3, 20.5.3 and earlier are affected by an out-of-bounds write 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-46253 | 1 Linux | 1 Linux Kernel | 2026-06-09 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: pstore/ram: fix buffer overflow in persistent_ram_save_old() persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied. | ||||