Export limit exceeded: 235489 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 235489 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (235489 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-31433 | 1 Linux | 1 Linux Kernel | 2026-05-23 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial OOB in get_file_all_info() for compound requests When a compound request consists of QUERY_DIRECTORY + QUERY_INFO (FILE_ALL_INFORMATION) and the first command consumes nearly the entire max_trans_size, get_file_all_info() would blindly call smbConvertToUTF16() with PATH_MAX, causing out-of-bounds write beyond the response buffer. In get_file_all_info(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2_file_all_info structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2_calc_max_out_buf_len() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATH_MAX) to ensure a safe copy operation. | ||||
| CVE-2026-43245 | 1 Linux | 1 Linux Kernel | 2026-05-23 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: ntfs: ->d_compare() must not block ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. | ||||
| CVE-2026-4682 | 1 Hp | 6 Deskjet 2800e All-in-one Printer Series, Deskjet 4200 All-in-one Printer Series, Deskjet 4200e All-in-one Printer Series and 3 more | 2026-05-23 | N/A |
| Certain HP DeskJet All in One devices may be vulnerable to remote code execution caused by a buffer overflow when specially crafted Web Services for Devices (WSD) scan requests are improperly validated and handled by the MFP. WSD Scan is a Microsoft Windows–based network scanning protocol that allows a PC to discover scanners (and MFPs) on a network and send scan jobs to them without requiring vendor specific drivers or utilities. | ||||
| CVE-2026-23263 | 1 Linux | 1 Linux Kernel | 2026-05-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/zcrx: fix page array leak d9f595b9a65e ("io_uring/zcrx: fix leaking pages on sg init fail") fixed a page leakage but didn't free the page array, release it as well. | ||||
| CVE-2026-5363 | 1 Tp-link | 2 Archer C7, Archer C7 Firmware | 2026-05-22 | 8.8 High |
| Inadequate Encryption Strength vulnerability in TP-Link Archer C7 v5 and v5.8 (uhttpd modules) allows Password Recovery Exploitation. The web interface encrypts the admin password client-side using RSA-1024 before sending it to the router during login. An adjacent attacker with the ability to intercept network traffic could potentially perform a brute-force or factorization attack against the 1024-bit RSA key to recover the plaintext administrator password, leading to unauthorized access and compromise of the device configuration. This issue affects Archer C7: through Build 20220715. | ||||
| CVE-2026-43417 | 1 Linux | 1 Linux Kernel | 2026-05-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Handle vfork()/CLONE_VM correctly Matthieu and Jiri reported stalls where a task endlessly loops in mm_get_cid() when scheduling in. It turned out that the logic which handles vfork()'ed tasks is broken. It is invoked when the number of tasks associated to a process is smaller than the number of MMCID users. It then walks the task list to find the vfork()'ed task, but accounts all the already processed tasks as well. If that double processing brings the number of to be handled tasks to 0, the walk stops and the vfork()'ed task's CID is not fixed up. As a consequence a subsequent schedule in fails to acquire a (transitional) CID and the machine stalls. Cure this by removing the accounting condition and make the fixup always walk the full task list if it could not find the exact number of users in the process' thread list. | ||||
| CVE-2026-43418 | 1 Linux | 1 Linux Kernel | 2026-05-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Prevent CID stalls due to concurrent forks A newly forked task is accounted as MMCID user before the task is visible in the process' thread list and the global task list. This creates the following problem: CPU1 CPU2 fork() sched_mm_cid_fork(tnew1) tnew1->mm.mm_cid_users++; tnew1->mm_cid.cid = getcid() -> preemption fork() sched_mm_cid_fork(tnew2) tnew2->mm.mm_cid_users++; // Reaches the per CPU threshold mm_cid_fixup_tasks_to_cpus() for_each_other(current, p) .... As tnew1 is not visible yet, this fails to fix up the already allocated CID of tnew1. As a consequence a subsequent schedule in might fail to acquire a (transitional) CID and the machine stalls. Move the invocation of sched_mm_cid_fork() after the new task becomes visible in the thread and the task list to prevent this. This also makes it symmetrical vs. exit() where the task is removed as CID user before the task is removed from the thread and task lists. | ||||
| CVE-2026-43433 | 1 Linux | 1 Linux Kernel | 2026-05-22 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: rust_binder: avoid reading the written value in offsets array When sending a transaction, its offsets array is first copied into the target proc's vma, and then the values are read back from there. This is normally fine because the vma is a read-only mapping, so the target process cannot change the value under us. However, if the target process somehow gains the ability to write to its own vma, it could change the offset before it's read back, causing the kernel to misinterpret what the sender meant. If the sender happens to send a payload with a specific shape, this could in the worst case lead to the receiver being able to privilege escalate into the sender. The intent is that gaining the ability to change the read-only vma of your own process should not be exploitable, so remove this TOCTOU read even though it's unexploitable without another Binder bug. | ||||
| CVE-2026-43434 | 1 Linux | 1 Linux Kernel | 2026-05-22 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: rust_binder: check ownership before using vma When installing missing pages (or zapping them), Rust Binder will look up the vma in the mm by address, and then call vm_insert_page (or zap_page_range_single). However, if the vma is closed and replaced with a different vma at the same address, this can lead to Rust Binder installing pages into the wrong vma. By installing the page into a writable vma, it becomes possible to write to your own binder pages, which are normally read-only. Although you're not supposed to be able to write to those pages, the intent behind the design of Rust Binder is that even if you get that ability, it should not lead to anything bad. Unfortunately, due to another bug, that is not the case. To fix this, store a pointer in vm_private_data and check that the vma returned by vma_lookup() has the right vm_ops and vm_private_data before trying to use the vma. This should ensure that Rust Binder will refuse to interact with any other VMA. The plan is to introduce more vma abstractions to avoid this unsafe access to vm_ops and vm_private_data, but for now let's start with the simplest possible fix. C Binder performs the same check in a slightly different way: it provides a vm_ops->close that sets a boolean to true, then checks that boolean after calling vma_lookup(), but this is more fragile than the solution in this patch. (We probably still want to do both, but the vm_ops->close callback will be added later as part of the follow-up vma API changes.) It's still possible to remap the vma so that pages appear in the right vma, but at the wrong offset, but this is a separate issue and will be fixed when Rust Binder gets a vm_ops->close callback. | ||||
| CVE-2026-43435 | 1 Linux | 1 Linux Kernel | 2026-05-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: rust_binder: fix oneway spam detection The spam detection logic in TreeRange was executed before the current request was inserted into the tree. So the new request was not being factored in the spam calculation. Fix this by moving the logic after the new range has been inserted. Also, the detection logic for ArrayRange was missing altogether which meant large spamming transactions could get away without being detected. Fix this by implementing an equivalent low_oneway_space() in ArrayRange. Note that I looked into centralizing this logic in RangeAllocator but iterating through 'state' and 'size' got a bit too complicated (for me) and I abandoned this effort. | ||||
| CVE-2005-4900 | 1 Google | 1 Chrome | 2026-05-22 | 5.9 Medium |
| SHA-1 is not collision resistant, which makes it easier for context-dependent attackers to conduct spoofing attacks, as demonstrated by attacks on the use of SHA-1 in TLS 1.2. NOTE: this CVE exists to provide a common identifier for referencing this SHA-1 issue; the existence of an identifier is not, by itself, a technology recommendation. | ||||
| CVE-2025-53766 | 1 Microsoft | 30 365 Copilot, Gdi+, Gdiplus and 27 more | 2026-05-22 | 9.8 Critical |
| Heap-based buffer overflow in Windows GDI+ allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2025-53732 | 1 Microsoft | 2 365 Copilot, Office | 2026-05-22 | 7.8 High |
| Heap-based buffer overflow in Microsoft Office allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-24285 | 1 Microsoft | 31 365 Copilot, Office, Office For Android and 28 more | 2026-05-22 | 7 High |
| Use after free in Windows Win32K allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-25180 | 1 Microsoft | 33 365 Copilot, Office, Office For Android and 30 more | 2026-05-22 | 5.5 Medium |
| Out-of-bounds read in Microsoft Graphics Component allows an unauthorized attacker to disclose information locally. | ||||
| CVE-2026-26110 | 1 Microsoft | 10 365 Apps, 365 Copilot, Office and 7 more | 2026-05-22 | 8.4 High |
| Access of resource using incompatible type ('type confusion') in Microsoft Office allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-26134 | 1 Microsoft | 2 365 Copilot, Office | 2026-05-22 | 7.8 High |
| Integer overflow or wraparound in Microsoft Office allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-47162 | 1 Microsoft | 10 365 Apps, 365 Copilot, Office and 7 more | 2026-05-22 | 8.4 High |
| Heap-based buffer overflow in Microsoft Office allows an unauthorized attacker to execute code locally. | ||||
| CVE-2025-47164 | 1 Microsoft | 10 365 Apps, 365 Copilot, Office and 7 more | 2026-05-22 | 8.4 High |
| Use after free in Microsoft Office allows an unauthorized attacker to execute code locally. | ||||
| CVE-2025-47167 | 1 Microsoft | 10 365 Apps, 365 Copilot, Office and 7 more | 2026-05-22 | 8.4 High |
| Access of resource using incompatible type ('type confusion') in Microsoft Office allows an unauthorized attacker to execute code locally. | ||||