Export limit exceeded: 15037 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 15037 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 10222 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10222 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-74292 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: tegra: tegra210_ahub: Validate written enum value tegra_ahub_put_value_enum() reads e->values[item[0]] before checking whether item[0] is within the enum item range. The existing check therefore happens too late to prevent an out-of-range read of the values array. Move the check before the array access. | ||||
| CVE-2026-74567 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: keys: fix out-of-bounds read in keyring_get_key_chunk() For description-level chunks keyring_get_key_chunk() advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup(desc, desc_len + 1) allocation. Compute the full byte offset and bounds-check the description against it before reading. The walk only reaches a description-level chunk when two keys collide through the hash, x, type and domain_tag chunks, so this is reached from an unprivileged add_key(2) with a crafted pair of same-type keys whose index hashes collide; KASAN reports a slab-out-of-bounds read. | ||||
| CVE-2019-11050 | 7 Canonical, Debian, Fedoraproject and 4 more | 8 Ubuntu Linux, Debian Linux, Fedora and 5 more | 2026-08-17 | 4.8 Medium |
| When PHP EXIF extension is parsing EXIF information from an image, e.g. via exif_read_data() function, in PHP versions 7.2.x below 7.2.26, 7.3.x below 7.3.13 and 7.4.0 it is possible to supply it with data what will cause it to read past the allocated buffer. This may lead to information disclosure or crash. | ||||
| CVE-2019-11046 | 6 Canonical, Debian, Fedoraproject and 3 more | 6 Ubuntu Linux, Debian Linux, Fedora and 3 more | 2026-08-17 | 3.7 Low |
| In PHP versions 7.2.x below 7.2.26, 7.3.x below 7.3.13 and 7.4.0, PHP bcmath extension functions on some systems, including Windows, can be tricked into reading beyond the allocated space by supplying it with string containing characters that are identified as numeric by the OS but aren't ASCII numbers. This can read to disclosure of the content of some memory locations. | ||||
| CVE-2026-74377 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path For non-SRQ QPs, the responder reads WQE fields directly from the shared queue buffer mapped into userspace. This allows a malicious user to modify fields like num_sge or sge entries while the kernel is processing the WQE, leading to out-of-bounds reads in rxe_resp_check_length() and copy_data(). Introduce get_recv_wqe() that validates num_sge and copies the WQE to a kernel-local buffer before processing, matching the approach already used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is reused since SRQ and non-SRQ paths are mutually exclusive per QP. | ||||
| CVE-2026-74444 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate DRAW_PRIMITIVES header size before division vmw_cmd_draw() computes maxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front. | ||||
| CVE-2026-72568 | 1 Redis | 1 Redis | 2026-08-17 | 7.1 High |
| Red Hat CNA-LR concluded that this CVE is not valid. | ||||
| CVE-2026-17550 | 1 Autodesk | 11 Advance Steel, Autocad, Autocad Architecture and 8 more | 2026-08-17 | 5.5 Medium |
| A maliciously crafted DWG or DXF file, when parsed through Autodesk AutoCAD, can force an Out-of-Bounds Read vulnerability. A malicious actor can leverage this vulnerability to cause a crash or disclose sensitive information. | ||||
| CVE-2026-74507 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: validate numbered report payloads When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed. KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added. The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds. Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload. | ||||
| CVE-2026-74333 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp-sdw-legacy: Bound DAI link iteration create_sdw_dailinks() walks soc_dais until it finds an entry with initialised cleared, but soc_dais is allocated with exactly num_ends entries. If all entries are initialised, the loop reads past the end of the array. This was reported by KASAN: BUG: KASAN: slab-out-of-bounds in mc_probe+0x26b3/0x2774 [snd_acp_sdw_legacy_mach] Read of size 1 Pass the allocated entry count to create_sdw_dailinks() and stop before reading past the array. | ||||
| CVE-2026-68743 | 3 Fedoraproject, Redhat, Sssd | 5 Sssd, Enterprise Linux, Openshift and 2 more | 2026-08-17 | 5.5 Medium |
| A flaw was found in SSSD. The extract_authtok_v1() function in the PAM responder does not validate the auth_token_length field against the remaining buffer size before processing. A local attacker can exploit this via a crafted protocol v1 request to the PAM responder socket, causing an out-of-bounds read and process crash, resulting in a denial of service. | ||||
| CVE-2026-74332 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp-sdw-sof: Bound DAI link iteration create_sdw_dailinks() walks sof_dais until it finds an entry with initialised cleared, but sof_dais is allocated with exactly num_ends entries. If all entries are initialised, the loop reads past the end of the array. Pass the allocated entry count to create_sdw_dailinks() and stop before reading past the array. | ||||
| CVE-2026-74340 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication The firmware-controlled rsp->count field is used as the loop bound for indexing into the flexible rsp->regs[] array without validation against the message length. A count exceeding the actual data causes out-of- bounds reads from the heap-allocated message buffer. Add a check that count fits within the received message. | ||||
| CVE-2026-5946 | 2 Isc, Redhat | 3 Bind, Bind 9, Hummingbird | 2026-08-17 | 7.5 High |
| Multiple flaws have been identified in `named` related to the handling of DNS messages whose CLASS is not Internet (`IN`) — for example, `CHAOS` or `HESIOD`, or DNS messages that specify meta-classes (`ANY` or `NONE`) in the question section. Specially crafted requests reaching the affected code paths — recursion, dynamic updates (`UPDATE`), zone change notifications (`NOTIFY`), or processing of `IN`-specific record types in non-`IN` data — can cause assertion failures in `named`. This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.48, 9.20.0 through 9.20.22, 9.21.0 through 9.21.21, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.48-S1, and 9.20.9-S1 through 9.20.22-S1. | ||||
| CVE-2026-74474 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() for transmit path header pulls In vxlan_xmit(), arp_reduce(), and vxlan_mdb_entry_skb_get(), pskb_may_pull() was being called to verify the availability of network layer headers (ARP, IPv6/ND, IP/IPv6 MDB keys). However, during transmit skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, len) only checks len bytes from skb->data rather than skb_network_offset(skb) + len, which can leave part of the network header in non-linear frags. Replace these remaining pskb_may_pull() calls with pskb_network_may_pull() to properly account for the MAC header offset. | ||||
| CVE-2026-74549 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Prevent access to unsupported weight registers Sashiko reports: During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements. In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN. Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes. The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers. | ||||
| CVE-2026-59128 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-08-17 | 5.5 Medium |
| Out-of-bounds read in Windows Encrypting File System (EFS) allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-61924 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-08-17 | 6.5 Medium |
| Out-of-bounds read in Remote Desktop Client allows an unauthorized attacker to disclose information over a network. | ||||
| CVE-2026-61933 | 1 Microsoft | 8 Windows 11 24h2, Windows 11 24h2, Windows 11 25h2 and 5 more | 2026-08-17 | 5.5 Medium |
| Out-of-bounds read in Windows DWM Core Library allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-62703 | 1 Microsoft | 18 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 15 more | 2026-08-17 | 5.5 Medium |
| Out-of-bounds read in Windows DWM Core Library allows an authorized attacker to disclose information locally. | ||||