Export limit exceeded: 10227 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10227 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-62742 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows Server 2012 and 11 more | 2026-08-17 | 6.5 Medium |
| Integer underflow (wrap or wraparound) in Windows DHCP Server allows an unauthorized attacker to disclose information over an adjacent network. | ||||
| CVE-2026-62745 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows Server 2012 and 11 more | 2026-08-17 | 6.5 Medium |
| Integer underflow (wrap or wraparound) in Windows DHCP Server allows an unauthorized attacker to disclose information over an adjacent network. | ||||
| CVE-2026-63528 | 1 Microsoft | 17 365 Apps, Microsoft 365, Microsoft 365 Apps For Enterprise and 14 more | 2026-08-17 | 5.5 Medium |
| Out-of-bounds read in Microsoft Office Word allows an unauthorized attacker to disclose information locally. | ||||
| CVE-2026-62796 | 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 NTFS allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-62876 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-08-17 | 7.8 High |
| Out-of-bounds read in Windows Win32K allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-65662 | 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 GDI allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-65784 | 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 NTFS allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-65786 | 1 Microsoft | 21 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 18 more | 2026-08-17 | 7.8 High |
| Heap-based buffer overflow in Desktop Window Manager allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-65787 | 1 Microsoft | 22 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 19 more | 2026-08-17 | 7.8 High |
| Heap-based buffer overflow in Desktop Window Manager allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-62842 | 1 Microsoft | 13 365 Apps, Microsoft 365, Microsoft Office 365 For Mac and 10 more | 2026-08-17 | 5.5 Medium |
| Out-of-bounds read in Microsoft Office allows an unauthorized attacker to disclose information locally. | ||||
| CVE-2026-72310 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer. Use size_add() for the offset plus length check so overflow is treated as out of bounds. | ||||
| CVE-2026-72297 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: net: atm: reject out-of-range traffic classes in QoS validation Reject ATM traffic classes above ATM_ANYCLASS in check_tp(). SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so accepting larger values leaves invalid traffic_class values in vcc->qos. That bad state later reaches pvc_info(), which indexes class_name[] with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause an out-of-bounds read when /proc/net/atm/pvc is read. Tighten the existing QoS validation so invalid traffic_class values are rejected at the point where user supplied QoS is accepted. | ||||
| CVE-2026-72195 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound attr_off in UpdateResidentValue against data_off In do_action()'s UpdateResidentValue case (fslog.c:3307), lrh->attr_off and lrh->redo_len come from the on-disk LRH. When they satisfy aoff + dlen < attr->res.data_off, the assignment attr->res.data_size = cpu_to_le32(aoff + dlen - data_off); underflows to ~4 GiB (e.g. 0xFFFFFFF9 when aoff=0x10, dlen=1, data_off=0x18). Subsequent code that reads attr->res.data_size to walk the resident attribute payload would then read up to 4 GiB past the 1024-byte MFT record allocation. The existing mi_enum_attr() defense in fs/ntfs3/record.c:287 catches the corrupted data_size on the next attribute walk and fails the mount, but only on the path that walks all attributes. A read site that picks an attribute by name and reads its data_size without re-validating is not covered. Validate aoff against data_off and asize at the source. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe: with aoff=0x10 and data_off=0x18, the post-assignment data_size is 0xfffffff9 (mount then fails at -22 from mi_enum_attr). [almaz.alexandrovich@paragon-software.com: clang-formatted the changes] | ||||
| CVE-2026-72209 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 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-72227 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 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-72129 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: sg->offset = off; sg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes "PAGE_SIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()). | ||||
| CVE-2026-72033 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client. | ||||
| CVE-2026-74399 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: evm: terminate and bound the evm_xattrs read buffer evm_read_xattrs() allocates size + 1 bytes, fills them from the list of enabled xattrs, and then passes strlen(temp) to simple_read_from_buffer(). When no configured xattrs are enabled, the fill loop stores nothing and temp[0] remains uninitialized, so strlen() reads beyond initialized memory. Explicitly terminate the buffer after allocation, use snprintf() for each formatted line, and pass the accumulated length, without risk of truncation, to simple_read_from_buffer(). | ||||
| CVE-2026-72396 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: hwmon: adm1275: Prevent reading uninitialized stack While adding support for the ROHM BD127X0 hot-swap controllers, sashiko reported an error in device-name comparison, which can lead to reading uninitialized stack memory. Quoting Sashiko: This is a pre-existing issue, but I noticed that just before this block in adm1275_probe(), there might be an out-of-bounds stack read: ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer); if (ret < 0) { ... } for (mid = adm1275_id; mid->name[0]; mid++) { if (!strncasecmp(mid->name, block_buffer, strlen(mid->name))) break; } Since i2c_smbus_read_block_data() reads up to 32 bytes into the uninitialized stack array block_buffer without appending a null terminator, strncasecmp() could read past the valid bytes returned in ret. For example, if the device returns a shorter string like "adm12", checking it against "adm1275" up to the length of "adm1275" will continue reading into uninitialized stack bounds. Prevent reading uninitialized memory by zeroing the stack array. | ||||
| CVE-2026-72241 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: leds: uleds: Fix potential buffer overread The name string supplied by userspace is not guaranteed to be null-terminated, so using strchr() on it might result in a buffer overread. The same thing will happen when said string is used by the LED class device. Fix this by using strnchr() instead and explicitly check that the name string is properly null-terminated. | ||||