Export limit exceeded: 15762 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (15762 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-106401 | 1 Google | 1 Chrome | 2026-10-07 | 9.6 Critical |
| Out of bounds write in Media in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-49878 | 1 Google | 1 Android | 2026-10-07 | 7.2 High |
| In wpas_handle_robust_av_scs_recv_action of robust_av.c, there is a possible out-of-bounds write due to a logic error in the code. This could lead to remote code execution with System execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-98323 | 1 Linux | 1 Linux Kernel | 2026-10-07 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Bound fragmented header copies by the remaining length siw_get_hdr() can receive an extended DDP/RDMAP header across more than one TCP callback. The first callback may receive most of the header, while the next one still limits the copy to hdrlen - MIN_DDP_HDR instead of the number of missing bytes. This makes the destination move past the end of the header and overwrite the receive state, including fpdu_part_rcvd. A later callback can then use a negative fpdu_part_rcvd value as a copy offset, which creates an OOB write. Use the number of header bytes already received when calculating the next copy length. | ||||
| CVE-2026-25273 | 1 Qualcomm | 1 Snapdragon | 2026-10-07 | 6.7 Medium |
| Memory Corruption when processing camera operations due to out-of-bounds write during driver updates. | ||||
| CVE-2026-77178 | 1 Oracle | 1 Virtualbox | 2026-10-07 | 9.1 Critical |
| Oracle VM VirtualBox before 7.2.8 allows guest OS users to cause an out-of-bounds write in the host OS in pcnetReceiveNoSync in DevPCNet.cpp in the PCNet (Am79C970A) network device model. | ||||
| CVE-2026-106115 | 1 Sixlabors | 1 Imagesharp | 2026-10-07 | 7.5 High |
| ImageSharp is a 2D graphics library. From 2.1.0 until 4.1.2, the TIFF CCITT Group 4 encoder allocates Width times rowsPerStrip bytes even though T6BitCompressor.CompressStrip can emit encoded row data and two 12-bit end-of-facsimile-block codes beyond that capacity. TiffCcittCompressor.WriteCode performs unchecked writes, and a decode-and-re-encode flow can inherit TiffCompression.CcittGroup4Fax and one-bit metadata from attacker-supplied input. The resulting out-of-bounds writes can corrupt memory and terminate the process. This issue is fixed in version 4.1.2. | ||||
| CVE-2026-106110 | 1 Sixlabors | 1 Imagesharp | 2026-10-07 | 7.5 High |
| ImageSharp is a 2D graphics library. From 2.0.0 until 4.1.2, the TIFF CCITT Group 3 encoder allocates an undersized compressed-data buffer for narrow 1-bit images. TiffCcittCompressor.Initialize does not reserve enough space for the row data and T4 end-of-line codes, and T4BitCompressor.CompressStrip reaches unchecked writes when TiffCompression.CcittGroup3Fax is selected directly or inherited from decoded TIFF metadata. An attacker-controlled encode or decode-and-re-encode flow can write beyond the logical output span, corrupt process memory, and terminate the process. This issue is fixed in version 4.1.2. | ||||
| CVE-2026-106112 | 1 Sixlabors | 1 Imagesharp | 2026-10-07 | 7.5 High |
| ImageSharp is a 2D graphics library. From 4.0.0 until 4.1.2, ICC LUT16 conversion accepts more than four output channels even though ClutCalculator.Calculate and LutEntryCalculator.CalculateLut store intermediate and output values in Vector4. When DecoderOptions.ColorProfileHandling is set to Convert, a malformed embedded profile can direct interpolation and output-LUT operations to write one float per declared channel beyond the four-float destination. This can corrupt memory and terminate the process; the default Preserve mode does not run ICC conversion. This issue is fixed in version 4.1.2. | ||||
| CVE-2026-106117 | 1 Sixlabors | 1 Imagesharp | 2026-10-07 | 7.5 High |
| ImageSharp is a 2D graphics library. From 3.0.0 until 4.1.1, decoding a strip TIFF using CCITT Group 3 or Modified Huffman compression can pass attacker-expanded runs to BitWriterUtils.WriteBits without first checking the current row width. T4TiffCompression.WritePixelRun can accumulate oversized makeup-code runs, and ModifiedHuffmanTiffCompression.Decompress validates the width only after writing. The unchecked writes can overflow the strip buffer, corrupt heap memory, and terminate the process. This strip-path vulnerability is distinct from the tiled decompressor-width mismatch. This issue is fixed in version 4.1.1. | ||||
| CVE-2026-106118 | 1 Sixlabors | 1 Imagesharp | 2026-10-07 | 7.5 High |
| ImageSharp is a 2D graphics library. From 3.0.0 until 4.1.1, tiled TIFF decoding allocates a destination buffer using TileWidth but TiffDecompressorsFactory.Create constructs T4, T6, and Modified Huffman decompressors using the full frame width. TiffDecoderCore.DecodeTilesChunky can therefore direct frame-width fax scanlines into a tile-width buffer when TileWidth is smaller than ImageWidth. The mismatch causes attacker-controlled out-of-bounds writes, heap corruption, and process termination even with legal per-row run codes. This tiled-path vulnerability is distinct from oversized CCITT runs in strip decoding. This issue is fixed in version 4.1.1. | ||||
| CVE-2026-98181 | 1 Linux | 1 Linux Kernel | 2026-10-07 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/gud: fix out-of-bounds write in gud_plane_atomic_check() The plane property loop uses req->properties[num_properties + i] as write index while simultaneously incrementing `num_properties` inside the loop. At iteration i, num_properties has also incremented by i, so the write is done at `initial_num_properties + 2*i`, skipping every other index and advancing by 2 per iteration. With just 2 connector and 32 plane properties the last write happens at index 64, one slot past the end of the 64-slot (indices 0–63) allocation. A USB device can trigger OOB by advertising the maximum number of properties. Fix by dropping the redundant `+ i`; num_properties is already the correct running index, as gud_connector_fill_properties() fills the preceding slots. | ||||
| CVE-2026-98371 | 1 Linux | 1 Linux Kernel | 2026-10-07 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: fix runt reassembly panic from short inner tot_len When the start of an inner packet is split across two outer packets such that fewer than 4 bytes land at the end of the first one, __input_process_payload() saves those bytes as a runt and skips the iplen/iphlen validation performed for in-place packets. When the continuation packet arrives, iptfs_reassem_cont() only requires the declared inner length to be >= sizeof(ra_runt) (6) before allocating the reassembly skb with that attacker-controlled length. However, __iptfs_iphlen() always returns the fixed minimum IP header size (20 for IPv4, 40 for IPv6), so for an inner IPv4 tot_len in [6, 19] the header-completion copy writes past the declared packet length, and the subsequent "ipremain -= copylen" underflows to ~4GB, leaving the payload copy length bounded only by blkoff (up to 64KB). At runtime the skb_put() tailroom check turns this into skb_over_panic(), i.e. an unprivileged kernel panic (DoS), reachable locally via userns+netns IPTFS SAs and remotely against IPTFS VPN gateways when the decrypted outer skb is linear (e.g. AF_PACKET taps, tun/tap delivery). Align the runt path with the normal path by requiring the declared inner length to cover at least the IP header size. This also subsumes the previous >= sizeof(ra_runt) check, since the minimum IP header is always larger than the runt buffer. This issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab. | ||||
| CVE-2026-102163 | 2026-10-06 | 8.8 High | ||
| On affected Arista access points with Wireless Intrusion Prevention System (WIPS) active, an unauthenticated attacker within radio frequency (RF) proximity can send a crafted frame to crash the sensor service, disabling WIPS monitoring on the access point, or potentially achieve remote code execution. No wireless association or authentication is required. | ||||
| CVE-2026-0482 | 1 Amd | 8 Alveo Accelerator Cards, Versal Ai Core Series Adaptive Socs, Versal Ai Edge Series Adaptive Socs and 5 more | 2026-10-06 | N/A |
| In AMD Versal™ Adaptive SoC devices, insufficient boundary checks in USB boot mode—when enabled through board modifications—could allow crafted images to trigger a buffer overflow and overwrite an active function pointer, which may result in arbitrary code execution during boot process. This condition could lead to potential impacts on confidentiality, integrity, and availability. | ||||
| CVE-2026-104036 | 2 Redhat, Sssd | 4 Enterprise Linux, Openshift, Openshift Container Platform and 1 more | 2026-10-06 | 5.8 Medium |
| A flaw was found in SSSD's NFS idmap plugin. When retrieving cached user or group names, the plugin detects if an entry exceeds the destination buffer size but fails to abort before copying data. A local attacker can trigger this vulnerability by requesting identity lookups that resolve to oversized cached entries, resulting in an out-of-bounds write. This flaw primarily leads to a Denial of Service (DoS) by crashing the identity mapping service, and may also corrupt adjacent process memory. | ||||
| CVE-2026-0461 | 1 Amd | 2 Kria Som, Zynq Ultrascale+ | 2026-10-06 | N/A |
| Insufficient boundary validation in the USB boot mode implementation of AMD Zynq™ UltraScale+ MPSoC and RFSoC devices could allow unbounded Device Firmware Upgrade (DFU) download requests to overflow the DDR receive buffer into FSBL memory, potentially resulting in unauthorized code execution during the boot process. This issue could impact the confidentiality, integrity, or availability of affected system. | ||||
| CVE-2026-98240 | 1 Linux | 1 Linux Kernel | 2026-10-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: initialize `options_len` before referencing options The following command triggers a kernel panic: ip link add d0 type dummy; ip link set d0 up ip route add 10.30.0.0/16 \ encap ip id 300 geneve_opts 4660:66:11223344 dev d0 memcpy: detected buffer overflow: 4 byte write of buffer size 0 kernel BUG at lib/string_helpers.c:1044! ... ip_tun_parse_opts.part.0.cold+0x10/0x10 ip_tun_build_state+0x116/0x2a0 On kernels built with GCC 15+ and `CONFIG_FORTIFY_SOURCE`, the fortified `memcpy()` got 0 sized destination with request of 4 bytes length: static int ip_tun_parse_opts_geneve(...) { ... attr = tb[LWTUNNEL_IP_OPT_GENEVE_DATA]; data_len = nla_len(attr); /* == 4 */ struct geneve_opt *opt = ip_tunnel_info_opts(info) + opts_len; memcpy(opt->opt_data, nla_data(attr), data_len); /* ^^^^^^^^^^^^^ 0 since options_len is assigned afterwards */ Fixed by initializing the counter before the options are referenced. Matching what `tunnel_key_opts_set()` already does. | ||||
| CVE-2026-73072 | 1 Vim | 1 Vim | 2026-10-06 | 7.3 High |
| Vim is an open source, command line text editor. Prior to 9.2.0846, set_sofo() in src/spellfile.c reuses sl_sal_first[] without resetting values left by set_sal_first(), so a crafted spell file containing an SN_SAL section before an SN_SOFO section causes under-counted mapping lists and attacker-influenced writes beyond a heap allocation. This issue is fixed in version 9.2.0846. | ||||
| CVE-2026-98272 | 1 Linux | 1 Linux Kernel | 2026-10-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: prevent buffer overflow in page_pool allocation The per‑processor buffering scheme is supported only if the number of pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS (8). This is already checked in mvpp2_probe() during the initial activation of percpu_pools. However, mvpp2_change_mtu() may later call mvpp2_bm_switch_buffers(priv, true) without this check, which can lead to an out-of-bounds access in the priv->page_pool array in mvpp2_bm_init(). The array is sized to hold MVPP2_PORT_MAX_RXQ entries, and mvpp2_get_nrxqs() may return exactly that value. The per-CPU scheme then doubles it to nrxqs * 2, exceeding the array bounds. Check that the hardware version is MVPP22 or newer and that the number of pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS before switching to per-CPU mode. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ||||
| CVE-2026-98199 | 1 Linux | 1 Linux Kernel | 2026-10-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/core) increase number of phases and add new mask Increase the number of phases to 16 as a new upcoming device supports such a number. While at it, add a new mask for controlling the source of the output voltage. Note (groeck): This patch was meant to prepare for support of MAX20826 and compatible devices, which support more than 10 phases per page. However, Sashiko reports that the mp2975 driver already supports up to 14 phases, and the mp2856 driver supports up to 12 phases. This already has the potential for out-of-bounds writes when probing the affected chips, making this patch a bug fix. | ||||