Export limit exceeded: 11014 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (11014 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-100387 | 1 Pgpointcloud | 1 Pointcloud | 2026-09-30 | 8.1 High |
| pgPointcloud through 1.2.5 contains a heap out-of-bounds read vulnerability in dimensional patch WKB deserialization that allows authenticated database users to read adjacent heap memory. Attackers can supply crafted pcpatch values with attacker-controlled size fields to copy heap memory into stored patches for exfiltration or crash the PostgreSQL backend. | ||||
| CVE-2026-68891 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-09-30 | 4.7 Medium |
| Out-of-bounds read in Microsoft Standard XPS allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-18857 | 1 Ibm | 35 Openbmc, Power System E1050 \(9043-mrx\), Power System E1050 \(9043-mrx\) Firmware and 32 more | 2026-09-30 | 3.4 Low |
| IBM OPENBMC FW1120.00 through FW1120.01, FW1110.00 through FW1110.31, and FW1060.00 through FW1060.81 is affected by a vulnerability in the BMC firmware management interface. The host system can cause the BMC firmware management service to crash or allow a limited amount of BMC internal memory to be read, resulting in a confidentiality and availability impact to the managed system. | ||||
| CVE-2026-18416 | 1 Zephyrproject | 1 Zephyr | 2026-09-30 | 3.7 Low |
| The CoAP link-format helper match_path_uri() in subsys/net/lib/coap/coap_link_format.c compares a registered resource path against the URI carried in a Uri-Query href= option. That URI is not NUL terminated, but the inner character loop advanced its index k once per path character without ever testing it against the option length len. When a registered path segment is longer than the supplied URI and the URI is a prefix of it, the loop reads uri[len] and beyond, past the end of the option value. The path is reached from coap_well_known_core_get_len() and coap_well_known_core_get() via match_queries_resource(), i.e. by any unauthenticated GET /.well-known/core?href=/<prefix> request to a device that serves /.well-known/core (for the CoAP server subsystem, CONFIG_COAP_SERVER_WELL_KNOWN_CORE, default y) and has at least one resource that declares struct coap_core_metadata attributes. The over-read does not reach the receive buffer. The well-known-core builders parse the query into a stack-local struct coap_option, whose value is a fixed array (value[12], or CONFIG_COAP_EXTENDED_OPTIONS_LEN_VALUE bytes) that the option bytes are copied into, so uri points into that copy. Reading past len therefore reads the unused, uninitialized tail of the array and, when the option fills it, the bytes just past it in the same stack frame. (In the ZoAP library of v1.8.0 to v1.9.x the option value was instead a pointer into the received packet, and the over-read ran past the option inside the packet buffer.) The impact is bounded. The number of bytes read past the end is limited by the length of the resource path segment, and each additional byte is only read if it happens to equal the next path character, so in practice the over-read is one byte. It also cannot influence the response: returning a match requires the final compared index to be len - 1 or len, both in bounds, so out-of-bounds bytes only ever steer the loop to the next candidate resource. The consequence is undefined behaviour, not information disclosure and not a matching error. The fix adds a k >= len guard at the top of the inner loop, so every uri[k] dereference is within the option value while still allowing a trailing * wildcard to match a longer path. | ||||
| CVE-2026-102318 | 1 Google | 1 Chrome | 2026-09-30 | 4.7 Medium |
| Out of bounds read in WebGL in Google Chrome prior to 154.0.8037.92 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-18747 | 1 Zephyrproject | 1 Zephyr | 2026-09-30 | 6.8 Medium |
| The MCUmgr SMP-over-console transport decodes a base64 frame, reads a 16-bit packet length from it, verifies a CRC and then unconditionally strips the trailing CRC with rx_ctxt->nb->len -= 2U; in mcumgr_serial_process_frag() (subsys/mgmt/mcumgr/transport/src/serial_util.c). mcumgr_serial_extract_len() accepted any declared length, including 0 and 1, and a packet declaring length 0 passes the checksum test for free because crc16_itu_t() over zero bytes returns the zero seed. Since net_buf::len is a uint16_t, the subtraction underflows and the buffer is handed to SMP claiming roughly 65 KB of payload while its data area is only CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE bytes (default 384). The trigger is a single unauthenticated 7-byte line on the management console — the 0x06 0x09 packet marker followed by the base64 group AAA= and a newline — delivered to any transport built on this helper: CONFIG_MCUMGR_TRANSPORT_UART (smp_uart.c) or CONFIG_MCUMGR_TRANSPORT_SHELL (smp_shell.c), both of which select MCUMGR_TRANSPORT_SERIAL_HAS_SMP_OVER_CONSOLE. No prior session state, fragmentation or credentials are required to trigger the underflow, and the malformed frame is mishandled before any command handler or command-level access control runs. The attacker only needs write access to that console, which on many boards is a USB CDC-ACM port rather than a bare UART header. With the inflated length, smp_process_request_packet() in subsys/mgmt/mcumgr/smp/src/smp.c loses its bound: cbor_nb_reader_init() gives the CBOR decoder a ~65 KB window into a 384-byte buffer, and each request header's nh_len is checked only against the inflated length. On its own the 7-byte frame re-parses whatever stale bytes the reused pool buffer still holds, typically a replay of the previously received request followed by a parse error, without leaving the buffer. Because the transport is unauthenticated, though, the attacker also controls the frames sent before the trigger, and can stage buffer contents so that a request succeeds with an nh_len larger than the buffer; net_buf_pull(), guarded only by __ASSERT_NO_MSG, then moves the parse cursor out of bounds and the loop reads further headers and CBOR from adjacent memory. The consequence is an out-of-bounds read that can fault the MCUmgr thread (denial of service); memory disclosure is also possible, since the default-enabled os echo handler (CONFIG_MCUMGR_GRP_OS_ECHO) decodes its string inside that window and copies it into its response. There is no integrity gain beyond what the unauthenticated transport already permits. The fix rejects any declared packet length of two bytes or fewer in mcumgr_serial_extract_len(), so the CRC-strip subtraction can no longer underflow. The identical pattern remains in the test-only loopback transport subsys/mgmt/mcumgr/transport/src/smp_dummy.c (CONFIG_MCUMGR_TRANSPORT_DUMMY), which has no external input path and therefore carries no practical exposure. | ||||
| CVE-2026-94286 | 1 X.org | 1 Libxtst | 2026-09-30 | 7.1 High |
| An out-of-bounds read in libXtst's RECORD reply parser in libXtst before 1.2.6 could be used by malicious X servers to crash attached X clients. | ||||
| CVE-2026-94285 | 1 X.org | 1 Libx11 | 2026-09-30 | 5.1 Medium |
| An out-of-bounds read in libX11's byte-oriented codeset parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients. | ||||
| CVE-2026-94284 | 1 X.org | 1 Libx11 | 2026-09-30 | 5.5 Medium |
| An out-of-bounds read vulnerability in libX11's XIM trigger-key registration parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients. | ||||
| CVE-2026-94283 | 1 X.org | 1 Libx11 | 2026-09-30 | 6.5 Medium |
| An out-of-bounds read vulnerability in libX11's XIM (X Input Method) attribute parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients. | ||||
| CVE-2026-69345 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-09-30 | 5.5 Medium |
| Out-of-bounds read in Microsoft Standard XPS allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-69303 | 1 Microsoft | 21 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 18 more | 2026-09-30 | 5.5 Medium |
| Out-of-bounds read in Push Message Routing Service allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-69308 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-09-30 | 5.5 Medium |
| Out-of-bounds read in Microsoft Standard XPS allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-69317 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-09-30 | 5.7 Medium |
| Out-of-bounds read in Remote Desktop Client allows an authorized attacker to disclose information over a network. | ||||
| CVE-2026-69329 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-09-30 | 7.5 High |
| Out-of-bounds read in BranchCache allows an unauthorized attacker to deny service over a network. | ||||
| CVE-2026-98041 | 1 Linux | 1 Linux Kernel | 2026-09-30 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Don't predict JMP32 pointer vs zero comparisons Consider the following program: r1 = map_value; /* low 32 bits are zero at runtime */ r6 = 0xdead000000000000; if w1 != 0 goto l1; l0: r1 += r6; r2 = *(u64 *)(r1 + 0); exit; l1: r6 = 0; goto l0; At the moment is_branch_taken() reports the jump as always taken, because it does not distinguish between BPF_JMP and BPF_JMP32 comparisons when processing 'if w1 != 0 ...'. | ||||
| CVE-2026-98145 | 1 Linux | 1 Linux Kernel | 2026-09-30 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: reject a command chain that carries no commands A chain whose command_count is zero passes the payload length check, because struct_size(payload, data, 0) is just the header. The fill loop then does not run, so offset stays zero and the request is submitted with a zero-length buffer. On firmware without AIE2_NPU_COMMAND that ends at the opcode check, since op is still ERT_INVALID_CMD and aie2_get_chain_msg_op() answers MSG_OP_MAX_OPCODE. aie2_get_npu_chain_msg_op() answers MSG_OP_CHAIN_EXEC_NPU whatever it is given, so there the submission continues to drm_clflush_virt_range(cmd_buf, 0), which reads the byte before the buffer and faults on the vmap guard page. EXEC_CMD is reachable by any process that can open the render node. Reject the request instead. | ||||
| CVE-2026-98117 | 1 Linux | 1 Linux Kernel | 2026-09-30 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: cachefiles: Fix potential UAF/KASAN warning Currently, trace_cachefiles_coherency() is being passed a pointer to a __be64 lain over the coherency data in struct cachefiles_xattr so that it can display the first 8 bytes. However, the data is of variable length and could even be 0 bytes. This could lead to a UAF or KASAN warning. Fix this by making sure the buffer has room for at least 8 bytes and that those 8 bytes are pre-cleared. Further, those bytes are not 8-byte aligned, so fix the tracepoint to extract the data as four 2-byte words (they are 2-byte aligned) and reassemble the __be64. The compiler will convert this into a single 8-byte load where the CPU supports it. | ||||
| CVE-2026-96420 | 1 Wireshark | 1 Wireshark | 2026-09-30 | 4.7 Medium |
| Toshiba file parser crash in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service | ||||
| CVE-2026-95390 | 1 Wireshark | 1 Wireshark | 2026-09-30 | 5.5 Medium |
| PEAK CAN TRC file parser crash in 4.6.0 to 4.6.8 allows denial of service | ||||