Total
15186 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-48420 | 2026-08-25 | 7.8 High | ||
| Substance3D - Sampler 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-71564 | 2026-08-25 | 7.8 High | ||
| Substance3D - Designer 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-48426 | 2026-08-25 | 7.8 High | ||
| Substance3D - Designer 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-63072 | 1 Openssl | 1 Openssl | 2026-08-25 | 7.5 High |
| Issue summary: OpenSSL CMS decryption sizes the key-unwrap output buffer based on querying the unwrapped key size, but the AES-WRAP-PAD unwrap primitive can write and cleanse more bytes than that query reports, causing an 8-byte out-of-bounds heap write. Impact summary: An attacker who supplies a crafted CMS message can trigger a deterministic 8-byte out-of-bounds heap write when the victim decrypts it with CMS_decrypt(), corrupting the heap and typically resulting in a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: The key-wrap OID is potentially attacker-controlled on the wire. CMS unwrapping allows both id-aesNNN-wrap-pad and id-aesNNN-wrap ciphers. An attacker can take a legitimate message and change a single OID byte to select the padded variant while leaving the message otherwise valid. Since the unwrap key is derived from the recipient's private operation (ECDH key agreement or ML-KEM decapsulation), the RFC 5649 integrity check cannot pass, and the decryption fails with integrity failure. The write is a fixed-size (8-byte), fixed-value (zero) heap overflow immediately past the allocation, requires no special configuration, and is reachable from the public CMS_decrypt() function. The consequence is a heap corruption leading to a Denial of Service. The fix in the CMS code sizes the unwrap output buffer for the worst case so a failed unwrap cannot write past the allocation. FIPS impact: no As the CMS code lives outside the FIPS module boundary, no FIPS modules are affected by this CVE. | ||||
| CVE-2026-77236 | 2 Amazon, Freertos | 2 Freertos, Freertos-kernel | 2026-08-25 | 7.3 High |
| Missing minimum size validation in secure context allocation in FreeRTOS-Kernel before 11.3.1 might allow local users to corrupt secure-world heap metadata via an out-of-bounds write with an undersized stack size parameter. To remediate this issue, users should upgrade to version 11.3.1 or later. | ||||
| CVE-2025-71407 | 1 Nokogiri | 1 Nokogiri | 2026-08-25 | 9.8 Critical |
| Nokogiri before 1.18.3 contains a stack buffer overflow vulnerability in libxml2 when reporting DTD validation errors with long QName prefixes, and a use-after-free vulnerability during validation against untrusted XML Schemas. Attackers can trigger these vulnerabilities by providing malicious DTD content or untrusted XSD files to cause denial of service or potential code execution. | ||||
| CVE-2026-68516 | 2026-08-25 | 6.5 Medium | ||
| OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.13, a crafted HTJ2K-compressed EXR can crash OpenEXR during normal decode. An HTJ2K-compressed EXR whose JPEG 2000 SIZ fields place the first tile outside the visible image can reach invalid tile and codeblock geometry in the vendored OpenJPH AVX2 decoder, causing a stack out-of-bounds write and denial of service. OpenEXR's HTJ2K path validates the decoded codestream dimensions against the EXR chunk size, but it does not reject SIZ image-offset/tile-grid geometry where the first tile does not intersect the image. This issue is fixed in version 3.4.14. | ||||
| CVE-2026-74682 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write on Type II inbound URBs data_ep_set_params() sizes each URB transfer buffer before it adds the Format Type II transfer delimiter: u->packets = urb_packs; u->buffer_size = maxsize * u->packets; if (fmt->fmt_type == UAC_FORMAT_TYPE_II) u->packets++; /* for transfer delimiter */ u->urb = usb_alloc_urb(u->packets, GFP_KERNEL); buffer_size is computed from the pre-increment packet count and never recomputed, so for a Type II endpoint the buffer is one packet short of the packet count the URB is built with. prepare_inbound_urb() then lays out one iso frame per packet and never consults buffer_size: offs = 0; for (i = 0; i < urb_ctx->packets; i++) { urb->iso_frame_desc[i].offset = offs; urb->iso_frame_desc[i].length = ep->curpacksize; offs += ep->curpacksize; } urb->transfer_buffer_length = offs; urb->number_of_packets = urb_ctx->packets; The last descriptor therefore points one packet past the end of the transfer buffer, where the host controller writes device data on every inbound transfer. prepare_silent_urb() and prepare_playback_urb() bound their fill loops by ctx->buffer_size, so only capture is affected. fmt_type comes from the device's audio streaming descriptors, so any device advertising a Type II capture format hits this once userspace sets hw_params on the stream. KASAN on 7.2.0-rc5 (arm64) with a dummy_hcd/raw-gadget device, one report per inbound transfer: BUG: KASAN: slab-out-of-bounds in dummy_timer Write of size 64 at addr ffff0000186171c0 by task cons02/166 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 166: usb_alloc_coherent snd_usb_endpoint_set_params The buggy address is located 0 bytes to the right of allocated 64-byte region [ffff000018617180, ffff0000186171c0) Compute buffer_size after the delimiter packet has been accounted for, and bound the fill loop by buffer_size, as prepare_silent_urb() already does on the outbound side. This grows every Type II URB allocation by one maxsize packet. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com> | ||||
| CVE-2026-74610 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: tls: don't leave a full plaintext sk_msg ring unpushed When the copy path in tls_sw_sendmsg_locked() adds the fragment that fills the plaintext sk_msg ring, it does not set full_record, so the record is left full and unpushed. A later splice() then adds to an already full ring: sk_msg_page_add() has no fullness check of its own, so sg.end wraps onto sg.start and the ring appears empty. Fragments added after that overwrite live entries, and sg.size no longer matches what is reachable between sg.start and sg.end, so pushing the record runs the scatterwalk off the end of the scatterlist. An unprivileged user can trigger this on a loopback TCP socket with the "tls" ULP attached: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:memcpy_from_scatterwalk+0x32/0xc0 Call Trace: skcipher_walk_next+0x1d1/0x2c0 gcm_encrypt_aesni_avx+0x1e9/0x220 bpf_exec_tx_verdict+0x3bb/0x860 tls_sw_sendmsg+0xa1a/0xca0 __sys_sendto+0x1da/0x1f0 Set full_record in the copy path when the ring becomes full, and push a record that is already full on entry to the sendmsg loop. | ||||
| CVE-2026-16996 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-25 | 8.8 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to execute arbitrary code due to an integer underflow. | ||||
| CVE-2026-17003 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-25 | 7.7 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to compromise the confidentiality and integrity of the system due to an out-of-bounds write. | ||||
| CVE-2026-17006 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-25 | 8.3 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to a heap buffer overflow. | ||||
| CVE-2026-17120 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-25 | 5.3 Medium |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to cause a denial of service due to a buffer overflow. | ||||
| CVE-2026-17122 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-25 | 9.8 Critical |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to a stack-based buffer overflow. | ||||
| CVE-2026-17141 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-25 | 9.8 Critical |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to a buffer overflow. | ||||
| CVE-2026-17152 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-25 | 9.8 Critical |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to a buffer overflow. | ||||
| CVE-2026-17157 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-25 | 9.8 Critical |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to a stack buffer overflow. | ||||
| CVE-2026-18832 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-25 | 8.8 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to a heap-based buffer overflow. | ||||
| CVE-2026-18828 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-25 | 5.4 Medium |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to cause a denial of service due to a stack-based buffer overflow. | ||||
| CVE-2026-17436 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-25 | 8.8 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to a heap-based buffer overflow. | ||||