Export limit exceeded: 376996 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (376996 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-64293 | 1 Linux | 1 Linux Kernel | 2026-08-12 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: iommufd: Use sizeof(*hdr) instead of sizeof(hdr) in veventq read The bound-check in iommufd_veventq_fops_read() for the normal vEVENT path uses sizeof(hdr) where the surrounding code uses sizeof(*hdr): if (!vevent_for_lost_events_header(cur) && sizeof(hdr) + cur->data_len > count - done) { hdr is declared as struct iommufd_vevent_header *, so sizeof(hdr) evaluates to the size of the pointer. Surrounding code uses sizeof(*hdr) consistently: if (done >= count || sizeof(*hdr) > count - done) { ... if (copy_to_user(buf + done, hdr, sizeof(*hdr))) { ... done += sizeof(*hdr); struct iommufd_vevent_header is currently 8 bytes (two __u32 fields, flags and sequence), so on 64-bit (sizeof(void *) == 8) the two expressions happen to be equal and the check works as intended. On 32-bit (sizeof(void *) == 4) the check under-counts the header by 4 bytes: a vEVENT whose data_len causes 8 + cur->data_len to exceed count - done while 4 + cur->data_len does not will pass the check, then the loop will copy_to_user 8 bytes of header followed by data_len bytes of payload, writing past the user-supplied buffer. It is also a latent bug for any future expansion of struct iommufd_vevent_header beyond sizeof(void *) on 64-bit; the check should not depend on the type happening to match the host pointer width. Use sizeof(*hdr) to match the rest of the function and the actual amount that will be copied. | ||||
| CVE-2026-64294 | 1 Linux | 1 Linux Kernel | 2026-08-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm: do file ownership checks with the proper mount idmap Ever since idmapped mounts were introduced, inode ownership checks (for side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done against the nop_mnt_idmap, which completely ignores the file's mount's idmap. This results in odd edgecases like: 1) mount/bind-mount with an idmap userA:userB:1 2) userB runs an owner_or_capable() check on file that is owned by userA on-disk/in-memory, but owned by userB after idmap translation 3) owner_or_capable() mysteriously fails as the correct idmap wasn't supplied In the case of mincore/madvise MADV_PAGEOUT, this is usually benign, because file_permission(file, MAY_WRITE) will probably succeed, as it uses the proper idmap internally, but it does not need to be the case on e.g a 0444 file where even the owner itself doesn't have permissions to write to it. Since this is clearly not trivial to get right, introduce a file_owner_or_capable() that can carry the correct semantics, and switch the various users in mm to it. The issue was found by manual code inspection & an off-list discussion with Jan Kara. | ||||
| CVE-2026-20349 | 1 Cisco | 2 Adaptive Security Appliance Software, Secure Firewall Threat Defense | 2026-08-12 | 8.6 High |
| A vulnerability in the Remote Access SSL VPN service for Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Cisco Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the device to reload unexpectedly, resulting in a denial of service (DoS) condition. This vulnerability is due to insufficient error checking when processing HTTP requests. An attacker could exploit this vulnerability by sending a crafted HTTP request to the Remote Access SSL VPN service on an affected device. A successful exploit could allow the attacker to cause the affected device to reload, resulting in a DoS condition. | ||||
| CVE-2026-64295 | 1 Linux | 1 Linux Kernel | 2026-08-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access The page_ext iteration API does not validate if the PFN still belongs to a valid section while advancing the iterator. When dynamically adding memory in the hotplug path, it can lead to a NULL pointer dereference during page_ext_lookup at the boundary of the last valid section when iterator count equals __pgcount. The for_each_page_ext() macro calls page_ext_iter_next() as its loop increment. for_each_page_ext() does a "__page_ext = page_ext_iter_next(&__iter)" at the end. This causes page_ext_iter_next() to increment iter->index past __pgcount and call page_ext_lookup(start_pfn + __pgcount). During memory hotplug (online), the PFN at start_pfn + __pgcount may belong to a section that has not yet been initialized, causing page_ext_lookup() to trigger a NULL pointer dereference. [ 14.555124][ T846] Call trace: [ 14.555125][ T846] lookup_page_ext+0x6c/0x108 (P) [ 14.555127][ T846] page_ext_lookup+0x30/0x3c [ 14.555129][ T846] __reset_page_owner+0x11c/0x260 [ 14.571201][ T846] __free_pages_ok+0x5e8/0x8e0 [ 14.571204][ T846] __free_pages_core+0x78/0xf0 [ 14.571206][ T846] generic_online_page+0x14/0x24 [ 14.597782][ T846] online_pages+0x178/0x30c [ 14.597784][ T846] memory_block_change_state+0x284/0x32c [ 14.597787][ T846] memory_subsys_online+0x4c/0x64 [ 14.597789][ T846] device_online+0x88/0xb0 [ 14.597791][ T846] online_memory_block+0x30/0x40 [ 14.597793][ T846] walk_memory_blocks+0xac/0xe8 [ 14.597794][ T846] add_memory_resource+0x280/0x298 [ 14.656161][ T846] add_memory+0x60/0x98 Move the iteration boundary enforcement inside the iterator functions, so callers cannot inadvertently access beyond the requested range. | ||||
| CVE-2026-68820 | 1 Microsoft | 20 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 17 more | 2026-08-12 | 7 High |
| Use after free in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-65673 | 1 Microsoft | 1 Microsoft Entra Connect | 2026-08-12 | 7.8 High |
| Improper neutralization of special elements used in an sql command ('sql injection') in Microsoft Entra Connect Sync allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-58641 | 1 Microsoft | 1 .net | 2026-08-12 | 7.8 High |
| Integer overflow or wraparound in .NET allows an unauthorized attacker to elevate privileges locally. | ||||
| CVE-2026-62886 | 1 Microsoft | 3 .net, Visual Studio 2022, Visual Studio 2026 | 2026-08-12 | 7.8 High |
| Integer overflow or wraparound in .NET allows an unauthorized attacker to elevate privileges locally. | ||||
| CVE-2026-62909 | 1 Microsoft | 3 .net, Visual Studio 2022, Visual Studio 2026 | 2026-08-12 | 7.8 High |
| Uncaught exception in .NET allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-65810 | 1 Microsoft | 2 .net, .net Framework | 2026-08-12 | 7.8 High |
| Relative path traversal in .NET Framework allows an unauthorized attacker to elevate privileges locally. | ||||
| CVE-2026-64296 | 1 Linux | 1 Linux Kernel | 2026-08-12 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: exfat: bound uniname advance in exfat_find_dir_entry() In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the output pointer by a fixed amount while the loop guard only tracks the accumulated name length: if (++order == 2) uniname = p_uniname->name; else uniname += EXFAT_FILE_NAME_LEN; len = exfat_extract_uni_name(ep, entry_uniname); name_len += len; unichar = *(uniname+len); *(uniname+len) = 0x0; uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len grows only by the actual extracted length, which is shorter when a name fragment contains an early NUL. The only guard is `name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short name fragments lets uniname run far past the p_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small, causing an out-of-bounds read and write at *(uniname+len). The sibling extractor exfat_get_uniname_from_ext_entry() already stops on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard added in commit d42334578eba ("exfat: check if filename entries exceeds max filename length")); exfat_find_dir_entry() never got the equivalent. Track the per-entry write offset as a count and reject a fragment once the offset, or the offset plus the extracted length, would exceed MAX_NAME_LENGTH, before forming the output pointer. | ||||
| CVE-2026-62897 | 1 Microsoft | 4 .net, .net Framework, Visual Studio 2022 and 1 more | 2026-08-12 | 7 High |
| Integer overflow or wraparound in .NET Framework allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-62732 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-08-12 | 7.8 High |
| Heap-based buffer overflow in Windows Telephony Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-62726 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-08-12 | 7 High |
| Use after free in Windows Telephony Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-62725 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-08-12 | 7 High |
| Use after free in Windows Telephony Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-62734 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-08-12 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Telephony Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-64298 | 1 Linux | 1 Linux Kernel | 2026-08-12 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: NFSv4: include MAY_WRITE in open permission mask for O_TRUNC POSIX requires write permission to truncate a file, so an open() that specifies O_TRUNC must be authorized for write access regardless of the O_ACCMODE access mode. nfs_open_permission_mask() builds the access mask passed to nfs_may_open(), which is the local authorization gate for OPENs the client serves itself from a cached write delegation via the can_open_delegated() path in nfs4_try_open_cached(). The mask is derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a file the caller cannot write requests only MAY_READ and passes the local check. The OPEN is then satisfied locally and the truncation is issued to the server as a SETATTR(size=0) over the delegation stateid, which the server accepts under standard write-delegation semantics. POSIX requires that this open fail with EACCES. Include MAY_WRITE in the mask whenever O_TRUNC is set so the local check matches the access the server would have enforced. | ||||
| CVE-2026-65795 | 1 Microsoft | 12 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 9 more | 2026-08-12 | 6.7 Medium |
| No cwe for this issue in Windows DNS allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-70348 | 1 Microsoft | 3 Windows 11 24h2, Windows 11 25h2, Windows 11 26h1 | 2026-08-12 | 5.5 Medium |
| Improper link resolution before file access ('link following') in Windows Management Services allows an authorized attacker to deny service locally. | ||||
| CVE-2026-65790 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-08-12 | 7.8 High |
| Heap-based buffer overflow in Windows Message Queuing allows an authorized attacker to elevate privileges locally. | ||||