Export limit exceeded: 11634 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (11634 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-73252 | 1 Cesanta | 1 Mongoose | 2026-10-22 | 7.5 High |
| Mongoose is an embedded web server and network library. Prior to 7.23, the built-in TLS stack selected by MG_TLS_BUILTIN in src/tls_builtin.c accepts a TLS 1.3 record whose decrypted size is exactly the 16-byte authentication tag with no plaintext or ContentType byte. In mg_tls_recv_record(), the msgsz length check permits that record and the recv_len calculation underflows to SIZE_MAX, so a later handshake step treats stale buffer contents as a trusted message with an effectively unbounded length. An unauthenticated malicious TLS peer can trigger a heap out-of-bounds read before certificate or Finished validation, causing a remote denial of service. This issue is fixed in version 7.23. | ||||
| CVE-2026-73260 | 1 Cesanta | 1 Mongoose | 2026-10-22 | 7.5 High |
| Mongoose is an embedded web server and network library. Prior to 7.23, the built-in TLS certificate parser selected by MG_TLS_BUILTIN fails to verify that a long-form DER element length fits within the remaining certificate buffer. In mg_der_to_tlv() and mg_der_next(), a peer-controlled length can advance the parser beyond the certificate and underflow the remaining uint32_t length, causing mg_tls_parse_cert_der() to continue walking an invalid pointer. An unauthenticated malicious TLS server, or a client presenting a certificate to a server configured for client certificates, can trigger an out-of-bounds read and denial of service during the handshake. This issue is fixed in version 7.23. | ||||
| CVE-2026-73261 | 1 Cesanta | 1 Mongoose | 2026-10-22 | 7.5 High |
| Mongoose is an embedded web server and network library. Prior to 7.23, the built-in TCP/IP stack enabled by MG_ENABLE_TCPIP in src/net_builtin.c does not reject a TCP option whose declared opts[1] length exceeds the remaining option bytes. In handle_opt(), a NOP followed by a truncated MSS option causes opts[3] to be read outside the declared options area and used as the low byte of dmss. An unauthenticated remote peer can corrupt the per-connection MSS value so later mg_send() calls transmit truncated or zero-length application payloads while the TCP connection otherwise appears healthy. This issue is fixed in version 7.23. | ||||
| CVE-2026-63626 | 1 Cesanta | 1 Mongoose | 2026-10-22 | 8.8 High |
| Mongoose is an embedded web server and network library. Prior to 7.23, ppp_handle_ipv6cp() in src/l2_ppp.c trusts the 16-bit IPv6CP len field without checking it against the received payload size. On a PPP or PPPoE link using MG_ENABLE_TCPIP and MG_ENABLE_IPV6, an unauthenticated adjacent peer can complete the required LCP exchange and send a short Configure-Request with an oversized length, causing ppp_tx_frame() to read beyond recv_queue.buf and write beyond tx.buf. The same length misuse can also expose adjacent heap bytes in a reply or hang the event loop through find_opt(). This issue is fixed in version 7.23. | ||||
| CVE-2026-98631 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: xsk: Use a 32-bit compare in xsk_map_gen_lookup xsk_map_gen_lookup() loads a u32 key and compares it with max_entries using BPF_JMP_IMM. BPF immediates are sign-extended to 64 bits, so a max_entries value of 0x80000000 or higher becomes a threshold larger than every zero-extended 32-bit key. An out-of-range index then skips the bounds check and the generated lookup reads past xsk_map[]. Compare with BPF_JMP32_IMM so the check stays in 32-bit unsigned range. | ||||
| CVE-2026-98640 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Validate PCI BAR size before mapping The amd_sfh driver maps PCI BAR 2 using pcim_iomap_regions() and subsequently accesses MMIO registers at offsets up to 0x10958 (e.g., AMD_P2C_MSG3 at 0x1068C). However, the driver never validates that the BAR size is large enough to cover these accesses. If the driver is bound to a device with a smaller BAR 2, this leads to an out-of-bounds memory access and a page fault during the probe function. For example, a page fault can occur when reading from privdata->mmio + AMD_P2C_MSG3 in mp2_select_ops(): BUG: unable to handle page fault for address: ffffc9000390368c PGD 100000067 P4D 100000067 PUD 1012c1067 PMD 105b64067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline] RIP: 0010:mp2_select_ops drivers/hid/amd-sfh-hid/amd_sfh_pcie.c:282 [inline] RIP: 0010:amd_mp2_pci_probe+0x337/0x5f0 drivers/hid/amd-sfh-hid/amd_sfh_pcie.c:487 Call Trace: <TASK> local_pci_probe drivers/pci/pci-driver.c:332 [inline] pci_call_probe drivers/pci/pci-driver.c:394 [inline] __pci_device_probe drivers/pci/pci-driver.c:455 [inline] pci_device_probe+0x431/0xc90 drivers/pci/pci-driver.c:489 Fix this by verifying that the length of BAR 2 is at least 128KB before attempting to map it. Since the maximum accessed offset is 0x10958, and PCI BAR sizes are powers of 2, any legitimate hardware will have a BAR size of at least 128KB. | ||||
| CVE-2026-98648 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: s390/uv: Prevent potential out-of-bounds read When the system has more than 85 secrets, the uv_secret_list struct array only holds up to 85 items per page, resulting in an out of bounds read in find_secret_in_page if the targeted secret is in the next page or not stored at all. Fix this by looping over the number of stored secrets which is the per sub-list count of stored secrets and not the overall count. | ||||
| CVE-2026-98658 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iio: proximity: aw96103: validate firmware data length The firmware parser reads a length from the binary header and then uses it to walk six-byte register/value entries. A truncated firmware image can make the parser read beyond the copied firmware buffer. A value smaller than the four-byte count field also underflows, producing a very large length. Read the little-endian field with get_unaligned_le32(), as previously proposed by David Lechner. Validate the header size, reject an underflowed length, ensure the resulting payload is contained in the firmware image, and require it to contain whole register/value entries. | ||||
| CVE-2026-98602 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 6.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix out-of-bounds reads on short RX/TX frames and control fallthrough Fix multiple out-of-bounds reads in Bluetooth BNEP frame processing: 1. In bnep_rx_frame() and bnep_ctrl_frame() (net/bluetooth/bnep/core.c), use pskb_may_pull() to verify the BNEP header, control type byte, filter count, and extension headers exist before reading them, and return 0 after handling BNEP_CONTROL instead of falling through to Ethernet frame submission when no extension headers follow. 2. In bnep_net_xmit() (net/bluetooth/bnep/netdev.c), verify skb->len >= ETH_HLEN with pskb_may_pull() before reading the 14-byte Ethernet header to prevent an out-of-bounds heap read and infoleak on short AF_PACKET TX frames. | ||||
| CVE-2026-98627 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 6.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve packet pointer class displacement in regsafe() regsafe() maps packet pointer IDs between states and checks that each current register range is a subset of the corresponding explored register range. It does not, however, preserve the displacement between registers that share a packet pointer ID. This is unsound because packet range is shared by ID. A bounds check on one class member updates every member, and a later access can consume the range through another member. Commit 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers") folded the fixed pointer offset into r64 and removed the old off equality check, so two individually narrower registers can prune even when their displacement has changed. The explored path can then license an out-of-bounds packet access on the pruned path. Require matching range bases for packet pointers with an ID. Together with the existing ID mapping, this preserves the displacement between members of each packet-pointer class without adding per-ID state. Packet pointers without an ID remain unaffected. | ||||
| CVE-2026-98643 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 2.3 Low |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds read of rtt_min in sock_ops A sockops prog reading skops->rtt_min never checks the sk type: on the tcp_conn_request() path sock_ops->sk is a request_sock (non-full), and the ctx rewrite casts it to a tcp_sock (full) and reads rtt_min past the end of the request_sock, returning dirty adjacent memory. SEC("sockops") int prog(struct bpf_sock_ops *skops) { switch (skops->op) { case BPF_SOCK_OPS_RWND_INIT: leak = skops->rtt_min; /* reads the request_sock OOB */ ... } } For instance one such read returned rtt_min=0xffff8881, the high half of a leaked kernel pointer. Guarding that cast is exactly what SOCK_OPS_GET_FIELD() does -- it checks is_locked_tcp_sock and returns 0 when sock_ops->sk is not a locked full socket. Every other tcp_sock field in sock_ops goes through it; rtt_min is the only one open-coded, so it skips the check. Read rtt_min through SOCK_OPS_GET_FIELD() too. rtt_min is a bit special: it is a struct minmax and we only want the current min, so pass rtt_min.s[0].v. That is equivalent to the old hand-computed offset offsetof(struct tcp_sock, rtt_min) + sizeof_field(struct minmax_sample, t) (s[0] sits at rtt_min + 0 and .v at + sizeof(.t), i.e. what minmax_get() returns), so the loaded field is unchanged and only the full-sock guard is added. The two BUILD_BUG_ON()s that protected the hand-computed offset are no longer needed. Before patch: 0: r1 = *(u64 *)(r1 +0) ; r1 = skops->sk 1: r1 = *(u32 *)(r1 +2324) ; ((tcp_sock *)sk)->rtt_min.s[0].v After patch: 0: *(u64 *)(r1 +56) = r9 1: r9 = *(u8 *)(r1 +50) ; is_locked_tcp_sock 2: if r9 == 0 goto pc+4 ; not a locked full sock -> 0 3: r9 = *(u64 *)(r1 +56) 4: r1 = *(u64 *)(r1 +0) ; r1 = skops->sk 5: r1 = *(u32 *)(r1 +2324) ; rtt_min.s[0].v 6: goto pc+2 7: r9 = *(u64 *)(r1 +56) 8: r1 = 0 | ||||
| CVE-2026-98687 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 6.8 Medium |
| In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject oversized XDomain properties responses tb_xdp_properties_request() allocates room for 45 data dwords in its 252-byte response buffer. The XDomain length field is six bits wide, however, and a malicious peer can set it to 63. After the fixed response fields are subtracted, the driver treats this as 48 data dwords. Commit 322e93448d90 ("thunderbolt: Clamp XDomain response data copy to allocation size") only bounds the copy against data_len. If data_len is at least 48, memcpy() reads 192 bytes from the 180-byte res->data array, causing a 12-byte heap out-of-bounds read. Commit 4db2bd2ed478 ("thunderbolt: Limit XDomain response copy to actual frame size") limits the earlier copy but does not constrain this header-derived length. Reject response data lengths that exceed the allocated source buffer before copying them into the assembled property block. | ||||
| CVE-2026-79843 | 1 Hpe | 1 Nonstop Sql/mx Exe | 2026-10-22 | 6.5 Medium |
| A corrupted file may cause out-of-bounds read in HPE NonStop SQL/MX EXE under certain conditions, potentially leading to information disclosure, process termination, CPU halt, or data corruption. | ||||
| CVE-2026-112394 | 1 Python-pillow | 1 Pillow | 2026-10-22 | 6.5 Medium |
| Pillow is a Python imaging library. Prior to 13.0.0, Pillow's P;2L and P;4L raw decoders can read past the end of an input buffer. ImagingRawDecode calculates a packed-pixel row size, while the unpackers read separately padded bit planes. A caller can supply a buffer and image dimensions whose accepted size is smaller than the unpacker's actual footprint. This can disclose up to three adjacent heap bytes in output pixels or crash the process. This issue is fixed in version 13.0.0. | ||||
| CVE-2025-71438 | 1 Gpac | 1 Mp4box | 2026-10-22 | N/A |
| An out-of-bounds read in gf_odf_ac4_cfg_dsi_v1 (/odf/descriptors.c) in GPAC Project/MP4Box before v26.07.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted AC4 file. | ||||
| CVE-2026-91334 | 1 Oracle | 5 Graalvm, Graalvm Enterprise Edition, Graalvm For Jdk and 2 more | 2026-10-22 | 3.7 Low |
| Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: ImageIO). Supported versions that are affected are Oracle Java SE: 8u503, 8u503-perf, 11.0.32.1, 17.0.20.1, 21.0.12.1, 25.0.4.1, 27; Oracle GraalVM for JDK: 17.0.20.1 and 21.0.12.1; Oracle GraalVM Enterprise Edition: 21.3.19.1.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N). | ||||
| CVE-2026-113095 | 1 Google | 1 Chrome | 2026-10-22 | 8.8 High |
| Out of bounds read in Focus in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-113102 | 1 Google | 1 Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in FileSystem in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113070 | 1 Google | 1 Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in GetUserMedia in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-43630 | 2 Ggml, Ggml-org | 2 Llama.cpp, Llama.cpp | 2026-10-22 | 6.5 Medium |
| llama.cpp builds b4882 before b8487 contain an out-of-bounds read vulnerability in the recurrent memory state restore path that allows attackers with write access to the slot save directory to read memory past the end of the allocated cells array. Attackers can craft a malicious slot file with an oversized seq_id value to trigger an out-of-bounds read that leaks heap data including pointer values into server logs, defeating ASLR protections and facilitating further exploitation. | ||||