Export limit exceeded: 11855 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (11855 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-68099 | 1 Linux | 1 Linux Kernel | 2026-08-23 | 5.9 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c). | ||||
| CVE-2026-64269 | 1 Linux | 1 Linux Kernel | 2026-08-23 | 9.1 Critical |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg When the server answers an RTRS READ, rdma_write_sg() builds the source scatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the peer. Its length is taken directly from the wire descriptor: plist->length = le32_to_cpu(id->rd_msg->desc[0].len); rd_msg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() -> process_read()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide local_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to max_chunk_size. msg_id and off are bounded against queue_depth and max_chunk_size in rtrs_srv_rdma_done(), but desc[0].len is a separate field that was not checked against the chunk size. A peer that advertises desc[0].len larger than max_chunk_size can make the posted RDMA write read past the chunk's mapped region. The resulting behaviour depends on the IOMMU configuration: with no IOMMU or in passthrough mode the read may extend into memory adjacent to the chunk and be returned to the peer, which can disclose host memory; with a translating IOMMU the out-of-range access is expected to fault and abort the connection. In either case the transfer exceeds what the protocol permits and is driven by a remote peer. Reject a descriptor length above max_chunk_size, mirroring the existing off >= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients do not exceed it: the client sets desc[0].len to its MR length, which is capped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE). | ||||
| CVE-2026-72156 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fpga: microchip-spi: fix zero header_size OOB read in mpf_ops_parse_header() mpf_ops_parse_header() reads header_size from the bitstream at MPF_HEADER_SIZE_OFFSET (24). When header_size is zero, the expression *(buf + header_size - 1) reads one byte before the buffer start. Since initial_header_size is set to 71 in mpf_ops, the fpga-mgr core guarantees the buffer is large enough to reach MPF_HEADER_SIZE_OFFSET. The only real gap is the zero header_size case, which cannot be resolved by providing a larger buffer, so return -EINVAL. | ||||
| CVE-2026-72209 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: ntfs: validate attribute values on lookup ntfs_attr_find() and ntfs_external_attr_find() check that generic resident attribute values fit in their attribute records and that fixed-size resident values are large enough. For variable-length resident formats, however, the fixed part is not enough: embedded length fields can still point callers past the resident value. A crafted image can set a small resident $FILE_NAME value_length while leaving file_name_length large. Callers then trust file_name_length and read past the resident value when converting or comparing the name. This was reproduced with a crafted image under KASAN as a slab-out-of-bounds read from the kmalloc-1k MFT record copy. The stack included ntfs_lookup(), ntfs_iget(), ntfs_read_locked_inode(), ntfs_attr_name_get(), ntfs_ucstonls(), and utf16s_to_utf8s(). Add a shared attribute value validator and use it before a lookup path can return an attribute, including the AT_UNUSED enumeration case where callers inspect returned attributes directly. The helper validates resident value bounds, minimum resident value sizes, variable-length $FILE_NAME fields, and non-resident mapping-pairs metadata that was previously checked separately in both lookup paths. This also preserves the intended resident @val matching semantics in the external attribute lookup path. The old duplicated validation block overwrote the actual resident value length with the type-specific minimum length before comparing @val, so variable-length resident values could fail to match even when the bytes were identical. Keep the comparison on the actual value length, and make ntfs_attrlist_entry_add() compare resident attributes with lowest_vcn zero instead of reading the non-resident union member after a successful resident match. Reject non-resident $FILE_NAME records too: the format requires $FILE_NAME to be resident and callers treat returned records as resident. | ||||
| CVE-2026-72210 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: ntfs: fix off-by-one in mapping pairs decoding bounds checks In ntfs_mapping_pairs_decompress(), attr_end points one byte past the end of the attribute record: attr_end = (u8 *)attr + le32_to_cpu(attr->length); The two bounds checks validating that mapping pair data bytes fit within the attribute use strict greater-than (>), which allows a one-byte out-of-bounds read when the data extends exactly to attr_end: b = *buf & 0xf; if (b) { if (unlikely(buf + b > attr_end)) // off-by-one goto io_error; for (deltaxcn = (s8)buf[b--]; b; b--) deltaxcn = (deltaxcn << 8) + buf[b]; } When buf + b == attr_end, the check evaluates to false and buf[b] reads one byte past the valid attribute boundary. The same pattern appears in the LCN delta bytes check. Fix both checks to use >= so that buf[b] at exactly attr_end is correctly rejected as out of bounds. | ||||
| CVE-2026-72227 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: batman-adv: mcast: avoid OOB read of num_dests header Before the access to struct batadv_tvlv_mcast_tracker's num_dests, it is attempted to check whether enough space is actually in the network header. But instead of using offsetofend() to check for the whole size (2) which must be accessible, offsetof() of is called. The latter is always returning 0. The comparison with the network header length will always return that enough data is available - even when only 1 or 0 bytes are accessible. Instead of using offsetofend(), use the more common check for the whole header. | ||||
| CVE-2026-72417 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset. | ||||
| CVE-2026-72480 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling ams_event_to_channel() may return a pointer past the end of dev->channels when no matching scan_index is found. This can lead to invalid memory access in ams_handle_event(). Add a bounds check in ams_event_to_channel() and return NULL when no channel is found. Also guard the caller to safely handle this case. | ||||
| CVE-2026-74295 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: hdac_hdmi: Validate written enum value hdac_hdmi_set_pin_port_mux() uses the written enum value to index the texts array before calling snd_soc_dapm_put_enum_double(), which validates that the value is within the enum item range. An out-of-range value can therefore make the driver read past the texts array before the helper rejects the write. Move the lookup after the helper has accepted the value. | ||||
| CVE-2026-74361 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1). | ||||
| CVE-2026-74419 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 7.3 High |
| In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Adjust size for copy_to_user() The amount of data returned to user space should be limited by the buffer size provided by the application. If the buffer is smaller than the data size, return only the portion that fits instead of failing. | ||||
| CVE-2026-70652 | 1 Libvips | 1 Libvips | 2026-08-21 | 5.0 Medium |
| libvips is a fast image processing library with low memory needs. Prior to version 8.18.3, libvips built with libultrahdr support can incorrectly size an output buffer in libvips/foreign/uhdrsave.c within vips_foreign_save_uhdr_set_raw_hdr when a pipeline enlarges an incoming JPEG to a very large output before encoding a gain map through VipsForeignSaveUhdr. The undersized allocation can cause a heap buffer over-read that may disclose adjacent data or crash the process. This issue is fixed in version 8.18.3. | ||||
| CVE-2026-62291 | 1 Struktur | 1 Libheif | 2026-08-21 | 5.3 Medium |
| libheif is a HEIF and AVIF file format decoder and encoder. In 1.23.0 and earlier, a crafted image sequence with a 2x2 primary plane and a 256x256 auxiliary alpha plane can cause attacker-controlled heap corruption during a normal decode and re-encode workflow. Track_Visual::decode_next_image_sample() calls transfer_channel_from_image_as() without checking that the auxiliary alpha dimensions match the main frame. The resulting inconsistent image reaches heif_track_decode_next_image() and then heif_context_encode_image(). In unc_encoder::encode(), unc_encoder_component_interleave::encode_tile() sizes its buffer with compute_tile_data_size_bytes() using the primary dimensions but copies each component using its actual plane dimensions. The oversized alpha plane is therefore copied beyond the allocation, causing an out-of-bounds write; the inverse size mismatch can also produce an out-of-bounds read. This issue is fixed in version 1.23.1. | ||||
| CVE-2026-74532 | 1 Linux | 1 Linux Kernel | 2026-08-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Validate length before parsing diagnostics TLV btintel_diagnostics() accesses tlv->val[0] without first validating that the diagnostics VSE is long enough to contain that field, so may cause reading data beyond the received frame. Fix by validating the length before access. | ||||
| CVE-2026-18278 | 1 Sony | 1 Xav-9500es | 2026-08-21 | N/A |
| Sony XAV-9500ES prh_l2_decode_packet Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows network-adjacent attackers to disclose sensitive information on affected installations of Sony XAV-9500ES devices. An attacker must first obtain the ability to pair a malicious Bluetooth device with the target system in order to exploit this vulnerability. The specific flaw exists within the handling of Bluetooth L2CAP packets. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the device. Was ZDI-CAN-28990. | ||||
| CVE-2026-69159 | 1 Freerdp | 1 Freerdp | 2026-08-21 | 5.4 Medium |
| ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2026-67306. Reason: This candidate is a duplicate of CVE-2026-67306. Notes: All CVE users should reference CVE-2026-67306 instead of this candidate. | ||||
| CVE-2026-65918 | 2 Linuxfoundation, Pytorch | 2 Torchvision, Vision | 2026-08-21 | 7.1 High |
| PyTorch torchvision through 0.28.0, fixed in commit 4e05dc2, contains an out-of-bounds heap read vulnerability in the GIF decoder's read_from_tensor callback that passes unclamped length to memcpy. Attackers can supply malicious or truncated GIF files to cause denial of service via segmentation fault or disclose adjacent heap memory contents. | ||||
| CVE-2026-70653 | 1 Libvips | 1 Libvips | 2026-08-21 | 3.3 Low |
| libvips is a fast image processing library with low memory needs. Prior to version 8.18.3, the old-style Radiance RLE decoder in libvips/foreign/radiance.c can process a repeat marker at the beginning of a scanline in scanline_read_old and read q[-1] before any prior pixel exists. A crafted Radiance image loaded through VipsForeignLoadRad can therefore disclose four bytes of adjacent heap data, most likely other image data. This issue is fixed in version 8.18.3. | ||||
| CVE-2026-55894 | 1 Capstone-engine | 1 Capstone | 2026-08-21 | 5.5 Medium |
| Capstone is a disassembly framework. In 6.0.0-Alpha9 and earlier, Capstone's arch/SH/SHDisassembler.c sh_disassemble() function computes an idx value from a raw 16-bit instruction without ensuring it is within the active mode-specific decode[] function-pointer table. An application using CS_ARCH_SH with CS_MODE_SH2A or CS_MODE_SH4A and CS_MODE_SHFPU can pass crafted bytecode through cs_disasm_iter() or cs_disasm(), causing the decode[idx] test to read outside the table and terminate the process with a segmentation fault. No code execution or information disclosure was demonstrated. This issue is fixed in version 6.0.0-Alpha10. | ||||
| CVE-2026-63383 | 1 Libevent Project | 1 Libevent | 2026-08-21 | 7.5 High |
| Libevent is an event notification library. Prior to 2.1.13 and 2.2.2-alpha, libevent can read beyond a contiguous evbuffer region in event_tagging.c when decode_tag_internal requests at most five bytes from evbuffer_pullup but iterates using the full logical buffer length. A fragmented evbuffer containing a six-byte malformed tag can therefore advance past the pullup window and trigger an out-of-bounds read, which can crash a process that decodes attacker-controlled tagged RPC data. This issue is fixed in versions 2.1.13 and 2.2.2-alpha. | ||||