Export limit exceeded: 424384 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 424384 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (424384 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-53329 | 1 Linux | 1 Linux Kernel | 2026-10-23 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as "capacity * vector->struct_size" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707) | ||||
| CVE-2026-53369 | 1 Linux | 1 Linux Kernel | 2026-10-23 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: udf: reject descriptors with oversized CRC length udf_read_tagged() skips CRC verification when descCRCLength + sizeof(struct tag) exceeds the block size. A crafted UDF image can set descCRCLength to an oversized value to bypass CRC validation entirely; the descriptor is then accepted based solely on the 8-bit tag checksum, which is trivially recomputable. Reject such descriptors instead of silently accepting them. A legitimate single-block descriptor should never have a CRC length that exceeds the block. | ||||
| CVE-2026-53399 | 1 Linux | 1 Linux Kernel | 2026-10-23 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: release layout stid on setlease failure nfs4_alloc_stid() publishes the new stid into cl->cl_stateids via idr_alloc_cyclic() under cl_lock before returning to nfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then fails, the error path frees the layout stateid directly with kmem_cache_free() without ever calling idr_remove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer. The correct teardown for an IDR-published stid is nfs4_put_stid(), which removes the IDR slot under cl_lock, dispatches sc_free (nfsd4_free_layout_stateid) to release ls->ls_file via nfsd4_close_layout(), and drops the nfs4_file reference in its tail. A second issue blocks that switch: nfsd4_free_layout_stateid() unconditionally inspects ls->ls_fence_work via delayed_work_pending() under ls_lock, but INIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work. nfsd4_alloc_layout_stateid() nfs4_alloc_stid() /* idr_alloc_cyclic under cl_lock */ nfsd4_layout_setlease() /* fails */ nfs4_put_stid() nfsd4_free_layout_stateid() delayed_work_pending(&ls->ls_fence_work) /* needs INIT */ nfsd4_close_layout() /* nfsd_file_put(ls->ls_file) */ put_nfs4_file() Fix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK initialization above the nfsd4_layout_setlease() call, and replace the manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup with a single nfs4_put_stid(stp). | ||||
| CVE-2026-63807 | 1 Linux | 1 Linux Kernel | 2026-10-23 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: <TASK> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK> Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization. | ||||
| CVE-2026-100070 | 1 Linux | 1 Linux Kernel | 2026-10-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: rewind offset when NAT shrinks the packet sashiko says: If map_addr() changes the packet length, such as when the public NAT IP string is shorter or longer than the internal IP, coff will still point to the offset relative to the pre-mangled packet. If the packet shrinks, coff could overshoot the correct position, potentially causing the next ct_sip_parse_header_uri() call to silently skip bytes and miss subsequent Contact headers. Could this lead to a failure to NAT those subsequent headers and leak internal network details? | ||||
| CVE-2026-79610 | 1 Xen | 1 Xen | 2026-10-23 | 8.8 High |
| XSA-501 was about issues with v1 -> v2 and v2 -> v1 changes racing certain other grant table operations. Sadly a v2 -> v1 -> v2 change has yet another effect which wasn't accounted for: During the first change, status pages would be freed. During the second change they would be allocated again. Hence across the full pair of change the addresses of the status pages may change, rendering stale previously calculated pointers into the status array. | ||||
| CVE-2026-79611 | 1 Xen | 1 Xen | 2026-10-23 | 5.5 Medium |
| For XSA-308 logic was introduced, as VMX VMEntry checks do not like the exact combination of state which occurs when #DB in intercepted, Single Stepping is active, and blocked by STI/MovSS is active, despite this being a legitimate state to be in. The resulting VMEntry failure is fatal to the guest. Sadly there is another special sub-case of the above, with branch tracing enabled. In that case the prior adjustment would still cause a VMentry failure, as before fatal to the guest. | ||||
| CVE-2026-102702 | 1 Xen | 1 Xen | 2026-10-23 | 7.5 High |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] 1) XSA-437 (CVE-2023-34321) addressed issues with overflows in calculations involved in guests flushing caches through GNTTABOP_cache_flush. Unfortunately the fix there introduced a calculation which may underflow, resulting in a loop which would - at least on 64-bit Arm - take excessively long, and which would likely eventually crash the hypervisor. This is CVE-2026-102699. 2) GNTTABOP_cache_flush may be issued on memory mapped from another domain using the grant table interface. However there was no restriction to disallow the use of invalidate-without-clean against read-only grant mappings, which may corrupt the granted memory. This is CVE-2026-102702. | ||||
| CVE-2019-5645 | 1 Rapid7 | 1 Metasploit | 2026-10-23 | 7.5 High |
| By sending a specially crafted HTTP GET request to a listening Rapid7 Metasploit HTTP handler, an attacker can register an arbitrary regular expression. When evaluated, this malicious handler can either prevent new HTTP handler sessions from being established, or cause a resource exhaustion on the Metasploit server. | ||||
| CVE-2026-43831 | 1 Advantech | 1 Adam-3600 | 2026-10-23 | 7.5 High |
| A stack-based buffer overflow vulnerability in the log message functionality could allow an unauthenticated attacker to achieve code execution. | ||||
| CVE-2026-43832 | 1 Advantech | 1 Adam-3600 | 2026-10-23 | 7.5 High |
| A stack-based buffer overflow vulnerability in the Cookie parsing methods could allow an unauthenticated attacker to achieve code execution when the SafeEnhancement feature is enabled. | ||||
| CVE-2026-43833 | 1 Advantech | 1 Adam-3600 | 2026-10-23 | 5.3 Medium |
| A stack-based buffer overflow vulnerability in the upload functionality could allow an authenticated attacker to achieve code execution. | ||||
| CVE-2026-18315 | 2 Themetechmount, Wordpress | 2 Truebooker-appointment-booking, Wordpress | 2026-10-23 | 9.8 Critical |
| The TrueBooker – Appointment Booking and Scheduler System plugin for WordPress is vulnerable to Authorization Bypass Through User-Controlled Key leading to Account Takeover in all versions up to, and including, 1.2.6. This is due to the admin_user_create_cus AJAX handler lacking any authentication or capability check before passing the attacker-supplied truebooker_wp_user_id parameter directly to wp_update_user. This makes it possible for unauthenticated attackers to overwrite the email address of any WordPress user — including an administrator — and then complete the standard WordPress lost-password flow to fully take over the targeted account. | ||||
| CVE-2026-6554 | 1 Tcpdump | 1 Libpcap | 2026-10-23 | 7.5 High |
| libpcap BPF interpreter treats the offset in the 'ja L' BPF instruction as a signed integer to implement looping via backward jumps, but it does not limit the number of loop iterations. A crafted filter program or the 'protochain' primitive used on a crafted network packet can cause the interpreter to loop infinitely. | ||||
| CVE-2026-79608 | 1 Xen | 1 Xen | 2026-10-23 | 9.8 Critical |
| The workaround for XSA-433 (Zenbleed, CVE-2023-20593) was later re-worked to better integrate with other manipulations of the same MSR. In this rework an inverted conditional was introduced, resulting in the workaround to not be applied when needed and vice versa. For more details, see: http://xenbits.xen.org/xsa/advisory-433.html | ||||
| CVE-2026-79609 | 1 Xen | 1 Xen | 2026-10-23 | 8.8 High |
| XPTI (Xen Page Table Isolation) was introduced to mitigate Meltdown (CVE-2017-5754, one aspect of XSA-254). This involves copying 64-bit PV guest page table entries from guest-chosen root page tables to the Xen- chosen one which is in actual use by hardware. To read the guest root page table, the directmap is used. PV guests, however, have a directmap which may not cover all memory; in particular this is the case if any memory extends beyond the 5 TiB (CONFIG_BIGMEM=y: 3.5 TiB) address boundary. | ||||
| CVE-2026-102699 | 1 Xen | 1 Xen | 2026-10-23 | 7.5 High |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] 1) XSA-437 (CVE-2023-34321) addressed issues with overflows in calculations involved in guests flushing caches through GNTTABOP_cache_flush. Unfortunately the fix there introduced a calculation which may underflow, resulting in a loop which would - at least on 64-bit Arm - take excessively long, and which would likely eventually crash the hypervisor. This is CVE-2026-102699. 2) GNTTABOP_cache_flush may be issued on memory mapped from another domain using the grant table interface. However there was no restriction to disallow the use of invalidate-without-clean against read-only grant mappings, which may corrupt the granted memory. This is CVE-2026-102702. | ||||
| CVE-2026-102700 | 1 Xen | 1 Xen | 2026-10-23 | 4.7 Medium |
| With its original introduction, GNTTAB_cache_flush was made available uniformly. XSA-232 (CVE-2017-14318) then covered an omitted NULL pointer check, yet the addition of that check failed to adjust the subsequent error path. That error path fails to drop a page reference in case the specified page is owned by a special system domain (DOM_IO and DOM_COW are system domains which can have memory pages assigned to them.) | ||||
| CVE-2026-104937 | 1 Shopware | 1 Shopware | 2026-10-23 | 8.1 High |
| Shopware version 6.7 allows the upload of attacker‑controlled HTML files and serves them as text/html without effective security headers, enabling stored cross-site scripting (XSS). When a malicious uploaded file containing an embedded JavaScript payload is viewed by an administrator, the attacker can access and exfiltrate the administrator's authentication token. The compromised token enables unauthorized access to the Shopware Administration API. If the affected administrator account possesses extension‑management privileges, an attacker can upload, install, and activate malicious plugins to achieve arbitrary PHP code execution on the underlying OS with the privileges of the Shopware process. | ||||
| CVE-2026-101678 | 2 Oracle, Oracle Corporation | 4 Mysql Connector/j, Mysql Connector\/j, Mysql Connectors and 1 more | 2026-10-23 | 4.3 Medium |
| Vulnerability in the MySQL Connectors product of Oracle MySQL (component: Connector/J). The supported version that is affected is 26.7.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Connectors. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Connectors. CVSS 3.1 Base Score 4.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L). | ||||