Export limit exceeded: 16062 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (16062 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-84286 | 1 Turboderp-org | 1 Exllamav3 | 2026-10-19 | 9.8 Critical |
| ExLlamaV3’s EXL3 loader uses an untrusted, model-supplied index to select a CUDA kernel without first verifying that the index is within bounds. A malicious model can force the code to read and invoke an out‑of‑range function pointer, resulting in a reproducible crash. Under specific conditions involving certain host memory layouts, it may be possible for an attacker to exploit this vulnerability to achieve controlled indirect kernel dispatch during model load. | ||||
| CVE-2026-56211 | 2 Aomedia, Redhat | 7 Libaom, Ai Inference Server, Enterprise Linux and 4 more | 2026-10-19 | 7.1 High |
| A remote code execution vulnerability was found in libaom, the reference AV1 codec implementation. Insufficient bounds validation in the AV1 encoder's SVC (Scalable Video Coding) layer ID control allows an attacker to supply crafted video frame pixels that overlap with internal encoder layer context structures. In fork-based video processing services, an attacker can use this to hijack the cyclic refresh map pointer, brute-force the process base address via a crash oracle, and redirect control flow to achieve arbitrary command execution. Exploitation requires the target service to use libaom with SVC encoding enabled and accept attacker-supplied video frames. | ||||
| CVE-2026-56209 | 2 Aomedia, Redhat | 7 Libaom, Ai Inference Server, Enterprise Linux and 4 more | 2026-10-19 | 7.1 High |
| An arbitrary address write vulnerability was found in libaom, the reference AV1 codec implementation. A missing bounds check in the SVC (Scalable Video Coding) layer ID control function allows an attacker to inject an arbitrary pointer into the cyclic refresh map field via crafted image pixel values. The encoder then writes approximately 1,200 bytes at the attacker-controlled address. This is fully deterministic and does not require a separate information leak. An attacker who can supply frames to a network-facing libaom encoder with SVC enabled could exploit this for denial of service or potential code execution. | ||||
| CVE-2026-98641 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: set up the frame pointer for the exception callback A program acting as exception boundary saves all callee-saved registers, so build_prologue() takes the exception_cb path and never calls push_callee_regs(). That is the only place find_used_callee_regs() runs, and with it the only place ctx->fp_used is set, so the callback prologue does not emit the mov x25, sp that points BPF_REG_FP at the frame the callback runs on. x25 keeps whatever it held when bpf_throw() was called. If the throw came from a subprogram that uses its own BPF stack, that is the subprogram's frame pointer, and since the subprogram never returns it never restores x25 either. Stack accesses through BPF_REG_FP are rewritten to be stack pointer relative, so those still land in the callback's own frame. Materializing the register does not: a callback that passes the address of a local variable to a helper hands over an address in the dead subprogram's frame. That address is below the callback's stack pointer by then, and the helper's own call chain covers it, so the helper can write over its own return address. 0x1234 below is the value the helper was asked to store: pc : 0x1234 lr : 0x1234 Call trace: 0x1234 (P) bpf_test_run+0x188/0x3e0 bpf_prog_test_run_skb+0x47c/0x998 __sys_bpf+0xbdc/0xdd8 Kernel panic - not syncing: Oops: Fatal exception in interrupt Set ctx->fp_used on the exception callback path so that the existing code further down sets x25 from the stack pointer. The epilogue restores it from the main program's save area along with the other callee-saved registers, as it already does. x86 sets the frame pointer for the callback from the argument it is passed, and powerpc computes it from the stack pointer. | ||||
| CVE-2026-98570 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 5.9 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: ipv6: keep room for the mac header in dst_dev_overhead() The seg6, ioam6 and rpl lwtunnels size their skb_cow_head() request as the length they are about to push plus dst_dev_overhead(), then push the new headers and rebuild the mac header below them with skb_mac_header_rebuild(). That rebuild needs skb->mac_len of headroom, but dst_dev_overhead() leaves LL_RESERVED_SPACE() of the egress device, 16 bytes for plain Ethernet. Where the mac header is longer than that, as it is on ingress through a VLAN device with reorder_hdr off, the rebuild runs out of room: skb_set_mac_header(skb, -skb->mac_len) computes a negative offset, stores it unchecked in the u16 skb->mac_header, and the memmove that follows writes skb->mac_len bytes about 64 KB past skb->head. Forwarding plain ping6 traffic through such a device reproduces it on all five seg6 encapsulation modes and on the rpl and ioam6 inline paths; skb->mac_header comes back as 65534 on a 704-byte head. Return the larger of the two. The helper already returns skb->mac_len when it has no dst, so this only makes the other branch agree, and it covers every caller rather than each call site in turn. | ||||
| CVE-2026-98532 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: do not let ipv6_find_hdr() return an offset past the packet end ipv6_find_hdr() walks the extension header chain, skipping each header by the length that header itself declares. ipv6_optlen() returns up to 2048, and the skip is never checked against skb->len, so the offset stored in *offset can point past the end of the packet. openvswitch installs that offset as the transport header, and update_ipv6_checksum() then reads and writes the transport checksum field out of bounds: BUG: KASAN: slab-use-after-free in inet_proto_csum_replace16+0x445/0x470 Read of size 2 at addr ffff88810b754b06 by task ovs_ipv6_oob/629 CPU: 4 UID: 1000 PID: 629 Comm: ovs_ipv6_oob Tainted: G N 7.3.0-rc3+ #348 Call Trace: inet_proto_csum_replace16+0x445/0x470 set_ipv6_addr+0x3dd/0x460 do_execute_actions+0x6a3d/0x7c40 ovs_execute_actions+0xfd/0x480 ovs_packet_cmd_execute+0xc38/0xf20 genl_rcv_msg+0x59e/0x870 netlink_rcv_skb+0x18b/0x450 genl_rcv+0x2d/0x40 netlink_unicast+0x6bc/0xa20 The buggy address belongs to the object at ffff88810b754980 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 390 bytes inside of freed 704-byte region [ffff88810b754980, ffff88810b754c40) Other callers use that offset too, so bound it here rather than in one caller. Reject a header whose declared length does not fit in the packet. ipv6_find_hdr() already fails with -EBADMSG on a malformed chain, so this adds no new failure mode. | ||||
| CVE-2026-98447 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: xfs: fix wild memcpy access when formatting ondisk rtrefcount btree roots LOLLM noticed that the inode btree root formatting methods copy too many bytes -- there's only one set of keys in node blocks, not two. This causes memory corruption of whatever's beyond the buffers. | ||||
| CVE-2026-93523 | 1 X.org | 1 X Server | 2026-10-18 | 7.8 High |
| A flaw was found in xorg-x11-server. A local authenticated client can exploit this flaw by sending a crafted input device ungrab request with an unvalidated modifier value. This lack of validation causes the server to perform an out-of-bounds write on the heap, resulting in memory corruption that can lead to a denial of service (DoS) or potential arbitrary code execution. | ||||
| CVE-2026-96521 | 1 Adobe | 1 Photoshop | 2026-10-18 | 7.8 High |
| Photoshop Desktop is 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-86573 | 2026-10-18 | 5.1 Medium | ||
| Out-of-bounds write vulnerability in Hitachi Disk Array Driver for AIX and Hitachi Disk Array Driver for Virtual I/O Server. This issue affects Hitachi Disk Array Driver for AIX: from 01-00 before 01-23-/A; Hitachi Disk Array Driver for Virtual I/O Server: from 01-04 before 01-23-/A. | ||||
| CVE-2026-86846 | 2 Dpdk, Redhat | 4 Dpdk, Enterprise Linux, Openshift and 1 more | 2026-10-18 | 6.5 Medium |
| A flaw was found in DPDK lib/vhost vhost-crypto. A guest can supply an avail-ring descriptor index that is used without bounds checking, causing an out-of-bounds write in the host vhost-crypto backend. | ||||
| CVE-2026-109311 | 1 Vllm | 1 Vllm | 2026-10-18 | 6.5 Medium |
| vLLM before 0.29.0 passes uploaded audio to the PyAV/FFmpeg av.open() fallback with only a file-size check, exposing FFmpeg's IAMF parser heap overflow. Authenticated remote attackers can repeatedly upload malformed IAMF containers to /v1/audio/transcriptions, corrupting the heap and crashing the API process. | ||||
| CVE-2026-109256 | 1 Freerdp | 1 Freerdp | 2026-10-18 | 5.3 Medium |
| FreeRDP 3.10.0 through 3.32.2 contains a heap buffer overflow in the WinPR png_write_data callback that writes past the buffer after a realloc failure. A malicious RDP clipboard peer can supply a large CF_DIB image that triggers out-of-bounds memcpy during PNG conversion, causing a client crash. | ||||
| CVE-2026-109251 | 1 Freerdp | 1 Freerdp | 2026-10-18 | 5.3 Medium |
| FreeRDP before 3.32.0 stores the server-supplied signed MS-RDPEGT geometry origin unchecked in an unsigned video surface coordinate, so the blit clamp in gdiVideoShowSurface() wraps in 32-bit arithmetic and is skipped. A malicious RDP server can send a negative topLevelLeft to clients connecting with /video, causing an out-of-bounds write of decoded H.264 picture data or a client abort. | ||||
| CVE-2026-83712 | 1 Microsoft | 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more | 2026-10-18 | 7.8 High |
| Out-of-bounds write in Windows NTFS allows an authorized attacker to execute code locally. | ||||
| CVE-2026-75084 | 1 Zephyrproject | 1 Zephyr | 2026-10-18 | 6.8 Medium |
| The CC1200 sub-GHz IEEE 802.15.4 driver takes the PHY packet length from the first byte of the radio's RX FIFO in get_packet_length() and validates it in verify_rxfifo_validity() (drivers/ieee802154/ieee802154_cc1200.c). That validation only enforced a lower bound (pkt_len < 3); its second clause rejects a FIFO that holds more bytes than declared and therefore never bounds large values. Because the driver configures the radio for variable packet length with PKT_LEN = 0xFF, the length byte is an over-the-air value of 0-255 that reached net_pkt_rx_alloc_with_buffer() and the subsequent SPI burst read unclamped. An unauthenticated attacker within radio range can transmit a frame that presents a length byte above the IEEE 802.15.4 maximum of 127 while the chip's 128-byte RX FIFO has not overflowed, so the driver's RX_FIFO_ERROR pre-check does not fire. Reaching this state depends on RF framing and timing, since the RX thread is driven off the PKT_SYNC_RXTX signal and may sample the FIFO before a packet is complete; no pairing, authentication, or user interaction is required. With the default CONFIG_NET_BUF_FIXED_DATA_SIZE and CONFIG_NET_BUF_DATA_SIZE=128, an allocation larger than one fragment is satisfied by a chain of fragments, but read_rxfifo_content() performs a single SPI burst of pkt_len bytes into the first fragment's buf->data and then calls net_buf_add() with the same length. A length above 128 therefore writes up to 127 bytes past the end of a fragment in the contiguous rx_bufs pool and leaves a net_buf whose len exceeds its capacity. The overflowing bytes are FIFO-underflow output rather than attacker-chosen data, so the practical impact is network-buffer-pool corruption and crashes rather than a controlled write. Only builds that enable CONFIG_IEEE802154_CC1200 with an attached CC1200 radio are affected. | ||||
| CVE-2026-70058 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows Server 2012 and 11 more | 2026-10-17 | 7.5 High |
| Out-of-bounds write in Windows DHCP Server allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-111157 | 1 Sox | 1 Sox | 2026-10-17 | 6.1 Medium |
| SoX through 14.4.2 contains a heap out-of-bounds write vulnerability in lsx_ms_adpcm_block_expand_i() in src/adpcm.c, triggered by an odd samplesPerBlock value in the WAV fmt chunk. Attackers can supply a crafted MS ADPCM WAV file to sox or any libsox consumer to write a partially controlled 16-bit sample past the heap buffer allocated by wav_ms_adpcm_fmt(). | ||||
| CVE-2026-96219 | 1 Microsoft | 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more | 2026-10-17 | 9.8 Critical |
| Out-of-bounds write in Windows Local Security Authority Subsystem Service (LSASS) allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-21116 | 1 Samsung Mobile | 1 Samsung Mobile Devices | 2026-10-17 | N/A |
| Out-of-bounds write in libsmkvextractor.so prior to SMR Oct-2026 Release 1 allows local attackers to write out-of-bounds memory. | ||||