Total
14837 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-8718 | 2026-08-26 | N/A | 8.4 HIGH | ||
| tls_opt_dtls_peer_connection_id_value_get() in subsys/net/lib/sockets/sockets_tls.c, which handles getsockopt(SOL_TLS, TLS_DTLS_PEER_CID_VALUE), passed the caller-supplied optval directly to mbedtls_ssl_get_peer_cid() without verifying the buffer was at least MBEDTLS_SSL_CID_OUT_LEN_MAX (default 32) bytes. mbedtls_ssl_get_peer_cid() copies the peer-negotiated DTLS Connection ID (length 1..MBEDTLS_SSL_CID_OUT_LEN_MAX) into that buffer without a destination-size parameter, so a caller-supplied optlen smaller than the CID causes a write of up to 31 bytes past the buffer end. In CONFIG_USERSPACE builds the getsockopt syscall verifier (z_vrfy_zsock_getsockopt) bounce-buffers the user's optval into a kernel allocation of exactly optlen bytes (k_usermode_alloc_from_copy -> z_thread_malloc), so an unprivileged user thread that passes a small optlen on a connected DTLS socket with Connection ID enabled induces a kernel-heap buffer overflow, with the overflowing content being the remote peer's CID. The defect requires CONFIG_MBEDTLS_SSL_DTLS_CONNECTION_ID, an established DTLS session with a negotiated peer CID, and (for the kernel-crossing case) CONFIG_USERSPACE. Introduced when the TLS_DTLS_CID option was added (v3.5.0). The fix rejects callers whose optlen is below MBEDTLS_SSL_CID_OUT_LEN_MAX with -EINVAL. | |||||
| CVE-2026-12052 | 2026-08-26 | N/A | 5.2 MEDIUM | ||
| The USB device-side CDC NCM class control-to-host handler usbd_cdc_ncm_cth in subsys/usb/device_next/class/usbd_cdc_ncm.c builds a fixed-size response for the GET_NTB_PARAMETERS (28-byte struct ntb_parameters) and GET_NTB_INPUT_SIZE (8-byte struct ntb_input_size) class requests and copies the whole structure into the control DATA IN buffer with net_buf_add_mem(buf, ..., sizeof(...)), ignoring the host-supplied wLength. The control DATA IN buffer is allocated by the USB stack with a capacity of exactly wLength bytes (usbd_ep_ctrl_data_in_alloc -> udc_ctrl_data_alloc -> net_buf_alloc_len(&udc_ep_pool, wLength); no round-up is applied for the IN endpoint). Because net_buf_add_mem/net_buf_simple_add only bounds the copy with an __ASSERT_NO_MSG, which is compiled out in production builds, a host that issues one of these standard CDC NCM control requests with a wLength smaller than the response structure (e.g. wLength = 1) causes the handler to memcpy up to 27 bytes past the end of the allocated pool buffer. The request fields come straight from the USB SETUP packet, so any host (or USB interposer) the Zephyr device enumerates against can trigger the overflow with no authentication once an image built with the device_next USB stack and the CDC NCM class is connected. The out-of-bounds write corrupts adjacent allocations and metadata in the shared udc_ep_pool, primarily causing memory corruption and denial of service of the USB stack; the overflow length is bounded (<= 27 bytes) and the written content is fixed device constants, and the bug reads nothing back so there is no information disclosure. The fix clamps the copy with MIN(sizeof(...), setup->wLength), matching the existing CDC ACM handler. | |||||
| CVE-2026-13216 | 2026-08-26 | N/A | 6.1 MEDIUM | ||
| The virtio PCI driver (drivers/virtio/virtio_pci.c) parses a device's PCI capability list during driver initialization. In virtio_pci_read_cap() the device-supplied capability length byte cap_len (read from PCI config space via pcie_conf_read()) was only checked with assert(tmp.cap_len == cap_struct_size). That assert resolves to __ASSERT_NO_MSG(), gated by CONFIG_ASSERT, which defaults off in production builds, so the value reached the copy logic completely unvalidated. The length then drives a loop that copies extra capability dwords into a fixed-size stack buffer supplied by the caller. A cap_len below the 24-byte base struct virtio_pci_cap underflows the unsigned extra_data_words count to a near-SIZE_MAX value, producing an effectively unbounded stack write; a cap_len above the caller's buffer (up to 255) writes up to roughly 228 bytes of device-controlled data past the buffer. Both are out-of-bounds writes of attacker-controlled content executed in kernel mode during boot-time device probe. The input originates from the virtio device. In the common deployment where Zephyr runs as a guest under a hypervisor, the device backend is the host, which already fully outranks the guest, so the bug yields no privilege escalation. The exploitable case is a virtio device that is untrusted relative to the Zephyr kernel — an untrusted or physical/passthrough virtio PCIe device on a bare-metal system, or a confidential-computing posture where the guest must defend against the host — where a malicious device can corrupt the kernel stack and potentially achieve code execution or a crash. The fix replaces the compiled-out assert with a runtime range check rejecting cap_len outside [sizeof(struct virtio_pci_cap), cap_struct_size] before any arithmetic or copy. | |||||
| CVE-2026-12363 | 2026-08-26 | N/A | 4.2 MEDIUM | ||
| The LoRaWAN Fragmented Data Block Transport service (subsys/lorawan/services/frag_transport.c) does not validate the fragment counter in a received DATA_FRAGMENT command before forwarding it to the configured decoder. In frag_transport_package_callback() the value frag_counter = hdr->frag_index_n & 0x3FFF is taken directly from the downlink payload and passed to the decoder, which derives an array index and flash offset as frag_counter - 1. DataFragment fragments are 1-indexed, so a frag_counter of 0 underflows that arithmetic. With the default Semtech/LoRaMAC-node decoder, this reaches FragDecoder.FragNbMissingIndex[fragCounter - 1] = 0; in FragDecoderProcess(), where fragCounter - 1 evaluates to -1 and writes a uint16_t zero out of bounds, just before the array and into the adjacent MatrixM2B recovery-matrix state of the static decoder object (CWE-787). A companion write derives a wild flash offset, but that path is rejected by the flash_area_write() bounds check. The in-tree low-memory decoder (frag_dec()) is not corrupted: its out-of-range bit-array and flash accesses are caught by sys_bitarray_ and flash_area_ bounds checks. The handler is the registered downlink callback for the fragmentation transport port, reachable whenever an active fragmentation session exists, so the triggering byte is attacker-influenceable LoRaWAN/FUOTA network input. Triggering it requires authenticated downlinks (LoRaWAN MAC session keys or a malicious/compromised network or FUOTA server) and an active fragmentation session. The impact is contained: corruption of decoder state and denial of the firmware-update (FUOTA) session rather than controllable memory corruption or code execution. The fix adds a transport-layer check that rejects frag_counter == 0, closing the defect for both decoder backends. | |||||
| CVE-2026-13215 | 2026-08-26 | N/A | 6.8 MEDIUM | ||
| The Zephyr ext2 filesystem driver fails to validate the s_log_block_size field of the on-disk superblock when mounting a filesystem. ext2_verify_disk_superblock() in subsys/fs/ext2/ext2_impl.c checks the magic number, revision, inode size and group counts, but never bounds s_log_block_size. On a successful verify, subsys/fs/ext2/ext2_ops.c computes fs->block_size = 1024 << superblock.s_log_block_size from this attacker-controlled uint32_t, so a crafted value either overflows the shift (undefined behaviour) or yields a block size far larger than CONFIG_EXT2_MAX_BLOCK_SIZE. That block size is then passed to k_mem_slab_init() by ext2_init_blocks_slab() to carve CONFIG_EXT2_MAX_BLOCK_COUNT blocks out of the fixed static buffer __ext2_block_memory_buffer, whose size is CONFIG_EXT2_MAX_BLOCK_COUNT * CONFIG_EXT2_MAX_BLOCK_SIZE. k_mem_slab_init() does not verify that the requested blocks fit the buffer, and the ext2 wrapper discards its return value, so the slab is laid out past the end of the static buffer. The mount immediately reads block-group, bitmap and inode blocks of fs->block_size bytes each into these slab blocks, producing an out-of-bounds write into adjacent static memory on the first block read. The entire path is gated only by data read from the mounted image, making this reachable by any attacker who can present a crafted ext2 image to a device that mounts it (for example a removable SD card or storage medium). Because the ext2 driver runs in kernel mode, supplying image bytes yields a supervisor-mode memory-corruption primitive, with impact ranging from denial of service to potential code execution. The fix rejects s_log_block_size values that overflow the shift (greater than 11) or that produce a block size exceeding CONFIG_EXT2_MAX_BLOCK_SIZE, so the block slab can no longer be initialized larger than its backing buffer. | |||||
| CVE-2026-78183 | 2026-08-26 | N/A | 9.8 CRITICAL | ||
| DBD::Pg version 3.21.0 for Perl has a heap out-of-bounds write in quote_float. quote_float() allocates the length of the string + 1, which is the size of the bare numeric symbol plus NULL. But for special literals NaN, Inf, +Inf, -Inf, Infinity, +Infinity, -Infinity it emits the literal surrounded by quotes plus NULL, which is length + 3 bytes. Every recognised literal (case-insensitive) overflows by 2 bytes, a single quote and a NULL. This can be reached by the $dbh->quote method, for example $dbh->quote( "Infinity", DBI::SQL_NUMERIC ). This regression was introduced in 3.21.0 by the quote.c rewrite. | |||||
| CVE-2026-19783 | 1 Ibm | 2 Aix, Vios | 2026-08-26 | N/A | 6.7 MEDIUM |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to cause kernel memory corruption due to insufficient validation. A crafted filesystem image can trigger an out-of-bounds kernel-stack write during directory reads, causing a system crash or potentially enabling privilege escalation. | |||||
| CVE-2026-42944 | 1 Nlnetlabs | 1 Unbound | 2026-08-26 | N/A | 7.5 HIGH |
| NLnet Labs Unbound 1.14.0 up to and including version 1.25.0 has a vulnerability that results in heap overflow when encoding multiple NSID and/or DNS Cookie EDNS and/or EDNS Padding options in the reply packet. The relevant options ('nsid', 'answer-cookie', 'pad-responses' (default)) need to be enabled for the vulnerability to be exploited. An adversary who can query Unbound can exploit the vulnerability by attaching multiple NSID and/or DNS Cookie EDNS and/or EDNS Padding options to the query. A flaw in the size calculation of the EDNS field truncates the correct value which allows the encoder to overflow the available space when writing. Those two combined lead to a heap overflow write of Unbound controlled data and eventually a crash. Unbound 1.25.1 contains a patch with a fix to de-duplicate the EDNS options and a fix to prevent truncation of the EDNS field size calculation. | |||||
| CVE-2026-18821 | 1 Ibm | 52 Power System E1050 \(9043-mrx\), Power System E1050 \(9043-mrx\) Firmware, Power System E1080 \(9080-hex\) and 49 more | 2026-08-25 | N/A | 7.5 HIGH |
| IBM PowerVM Hypervisor FW1120.00, FW1110.00 through FW1110.30, FW1060.00 through FW1060.80, and FW950.00 through FW950.H2 Power Systems Firmware is affected by a vulnerability in partition firmware during network boot. An unauthenticated attacker on the same network as a partition undergoing network boot can send a malformed packet, allowing arbitrary code to be executed in the partition firmware and compromising everything subsequently loaded by that partition. Other partitions and the managed system are not affected. Only partitions actively performing a network boot are affected, resulting in a confidentiality, integrity, and availability impact. | |||||
| CVE-2026-17100 | 1 Ibm | 58 Power Hardware Management Console \(7063-cr2\), Power Hardware Management Console \(7063-cr2\) Firmware, Power System Ac922 \(8335-gth\) and 55 more | 2026-08-25 | N/A | 8.2 HIGH |
| Power Systems Firmware FW1120.00, FW1110.00 through FW1110.30, FW1060.00 through FW1060.80, FW950.00 through FW950.H2, OP940.00 through OP940.a1, and OP940.00 - OP940.81 is affected by a vulnerability in the service processor mailbox interface. An attacker with authenticated service-level access to the BMC/FSP can exploit this vulnerability, allowing arbitrary code to be executed in the host firmware runtime, giving full control over the managed system, resulting in a confidentiality, integrity, and availability impact to the managed system. | |||||
| CVE-2021-4090 | 2 Linux, Netapp | 17 Linux Kernel, H300e, H300e Firmware and 14 more | 2026-08-25 | 6.6 MEDIUM | 7.1 HIGH |
| An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. | |||||
| CVE-2026-18842 | 1 Ibm | 2 Aix, Vios | 2026-08-25 | N/A | 8.4 HIGH |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to gain elevated privileges due to an out-of-bounds write. | |||||
| CVE-2026-77236 | 1 Amazon | 1 Freertos | 2026-08-25 | N/A | 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-2026-72852 | 2026-08-25 | N/A | 7.8 HIGH | ||
| hank-ai/darknet sizes a convolutional layer's weight and output heap buffers by multiplying configuration fields taken from a .cfg file in unchecked 32-bit int arithmetic. In src-lib/convolutional_layer.cpp, l.nweights is computed as (c / groups) * n * size * size and l.outputs as l.out_h * l.out_w * l.out_c, and both feed xcalloc directly. A .cfg whose true dimension product exceeds INT_MAX wraps to a small or zero value, so the allocation is undersized; for example width and height of 256 with filters of 65536 gives 2^32, which wraps to 0. forward_convolutional_layer then re-derives the GEMM dimensions with a different operand order, computing k as l.size*l.size*l.c / l.groups where the allocation divided before multiplying, and reads and writes through the undersized buffer. Loading the crafted .cfg for inference or training is sufficient and no valid .weights file is required. The reported proof of concept observed a heap buffer overflow read in gemm_nn_fast under AddressSanitizer and glibc allocator metadata corruption in a release build of the same input, indicating an out-of-bounds write. | |||||
| CVE-2026-16996 | 1 Ibm | 2 Aix, Vios | 2026-08-25 | N/A | 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 | 2 Aix, Vios | 2026-08-25 | N/A | 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-17120 | 1 Ibm | 2 Aix, Vios | 2026-08-25 | N/A | 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 | 2 Aix, Vios | 2026-08-25 | N/A | 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 | 2 Aix, Vios | 2026-08-25 | N/A | 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 | 2 Aix, Vios | 2026-08-25 | N/A | 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. | |||||