Export limit exceeded: 11793 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (11793 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| 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-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-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. | ||||
| CVE-2026-113329 | 2 Apple, Google | 2 Macos, Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in Installer in Google Chrome on on Mac prior to 156.0.8078.47 allowed a remote attacker to potentially read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113199 | 1 Google | 1 Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in Payments 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-113054 | 1 Google | 1 Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in SiteIsolation 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-113050 | 1 Google | 1 Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in HID 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-113151 | 1 Google | 1 Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in Actor 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-56386 | 1 Apache | 1 Brpc | 2026-10-22 | 7.5 High |
| Integer underflow and out-of-bounds read in the HTTP/2 server DATA frame parser in Apache bRPC allows an unauthenticated remote attacker to cause denial of service by sending a malformed DATA frame with the PADDED flag set and a zero-length payload. Root Cause: The HTTP/2 DATA frame handler computed the fragment size from the attacker-controlled payload length and, when the PADDED flag was present, decremented the fragment size before ensuring that the frame contained the mandatory pad length byte. A zero-length padded DATA frame could therefore underflow the unsigned fragment size and read the pad length byte past the end of the frame buffer. Affected Scenarios: Apache bRPC servers that accept HTTP/2 traffic are affected when a remote client can send crafted HTTP/2 frames to the server. HTTP/2 may be reached through cleartext h2c detection on an HTTP port or through TLS ALPN negotiation. How to Fix: (Choose one of the following options) 1. Upgrade Apache bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3325 Note: The fix validates that a padded DATA frame has enough payload bytes for the pad length field before decrementing the fragment size or reading the pad length byte. Malformed zero-length padded DATA frames are rejected with HTTP/2 FRAME_SIZE_ERROR. | ||||
| CVE-2026-113233 | 1 Google | 2 Android, Chrome | 2026-10-22 | 8.8 High |
| Out of bounds read in Core in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker to potentially execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113277 | 1 Google | 2 Android, Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in CustomTabs in Google Chrome on on Android 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-113295 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-10-22 | 6.5 Medium |
| Out of bounds read in ANGLE in Google Chrome on on Windows prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-112278 | 1 Rdesktop | 1 Rdesktop | 2026-10-22 | 6.5 Medium |
| rdesktop through 1.9.0 contains a heap out-of-bounds read vulnerability in process_raw_bmpcache() in orders.c that allows malicious RDP servers to crash clients. Attackers can send a raw bitmap cache order declaring large width, height, and bpp values with a tiny payload, causing memcpy() to read past the receive buffer and crash the client. | ||||
| CVE-2026-112273 | 1 Libtins | 1 Libtins | 2026-10-22 | 5.3 Medium |
| libtins through 4.6 contains a heap out-of-bounds read vulnerability in DNS::compose_name in src/dns.cpp that allows remote attackers to read past the packet buffer by sending a label ending exactly at the packet end. Attackers can deliver crafted DNS packets whose additional, answer, or authority records trigger a one-byte read when parsed, crashing applications on hardened allocators. | ||||
| CVE-2026-112020 | 1 Lodev | 1 Lodepng | 2026-10-22 | 6.1 Medium |
| LodePNG through 20261006 contains a heap out-of-bounds read vulnerability in lodepng::getFilterTypesInterlaced() in lodepng_util.cpp that lacks bounds checks on decompressed IDAT data. Attackers can supply a crafted interlaced PNG declaring a raster larger than its IDAT stream to disclose adjacent heap memory or crash applications. | ||||
| CVE-2026-98149 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix percpu map update indexing with sparse CPU IDs Per-CPU array, hash, and cgroup storage map updates without BPF_F_CPU or BPF_F_ALL_CPUS use a value buffer whose per-CPU slots are packed in possible-CPU order. The buffer is sized as: round_up(value_size, 8) * num_possible_cpus() The update paths iterate over possible CPUs, but use the logical CPU ID to calculate the source offset: value + size * cpu This only works when possible CPU IDs are contiguous starting at zero. For example, with a possible CPU mask of 0,2-3, the buffer contains three slots corresponding to CPUs 0, 2, and 3. CPU2 is therefore expected to use slot 1 and CPU3 slot 2. Instead, the current code uses slots 2 and 3 respectively, causing incorrect per-CPU values and an out-of-bounds read from the update buffer for CPU3. The corresponding lookup paths already use a dense offset while iterating over possible CPUs. Do the same for the array, hash, and cgroup storage update paths, advancing the source offset once for each possible CPU. BPF_F_ALL_CPUS continues to use the same value for every CPU. | ||||
| CVE-2026-103857 | 1 Adobe | 2 Adobe Framemaker 2022, Adobe Framemaker 2026 | 2026-10-21 | 5.5 Medium |
| Adobe Framemaker is affected by an out-of-bounds read vulnerability that could lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to disclose sensitive information. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||