Export limit exceeded: 48976 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (48976 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2021-47996 | 2 Nokogiri, Sparklemotion | 2 Nokogiri, Nokogiri | 2026-08-28 | 7.5 High |
| Nokogiri before 1.11.4 (CRuby implementation only, when the packaged/vendored libxml2 is used) bundles libxml2 2.9.10, which is affected by multiple vulnerabilities addressed in libxml2 2.9.12, including a memory leak in xmlSchemaValidateStream (CVE-2019-20388), a global buffer over-read in xmlEncodeEntitiesInternal (CVE-2020-24977), a heap-based buffer overflow (CVE-2021-3517), and an out-of-bounds read (CVE-2021-3518). Processing crafted XML documents may lead to denial of service, information disclosure, or memory corruption. | ||||
| CVE-2026-80569 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer rmi_f54_work() reads a diagnostics report from the device into f54->report_data, sizing the transfer with rmi_f54_get_report_size(): report_size = rmi_f54_get_report_size(f54); ... for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) { int size = min(F54_REPORT_DATA_SIZE, report_size - i); ... rmi_read_block(.., f54->report_data + i, size); } report_data is allocated once at probe from F54's own electrode counts (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))), but rmi_f54_get_report_size() computes the size from drv_data->num_*_electrodes when those are set, i.e. from the F55 function's electrode counts. Both counts come straight from device queries (F54 and F55 each report up to 255 electrodes) and nothing constrains the F55 counts to the F54 ones. A malicious or malfunctioning RMI4 device that reports larger F55 electrode counts than its F54 counts makes report_size exceed the allocation, so the read loop writes past report_data (and the V4L2 dequeue memcpy() then reads past it). On conforming hardware the F55 configured electrodes are a subset of the F54 physical electrodes, so report_size never exceeds the buffer and well-behaved devices are unaffected. Record the allocation size and reject a report that does not fit, mirroring the existing zero-size check. | ||||
| CVE-2026-80605 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: HID: picolcd: prevent NULL pointer dereference in picolcd_send_and_wait() In picolcd_send_and_wait(), an integer overflow of the signed loop counter 'k' can theoretically lead to a NULL pointer dereference of 'raw_data'. If the loop executes more than INT_MAX times, 'k' becomes negative, making the condition 'k < size' true even when 'size' is 0. Change the type of 'k' to 'unsigned int' to prevent the overflow and eliminate the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. [jkosina@suse.com: extended hash length] | ||||
| CVE-2026-78009 | 1 Watchguard | 1 Fireware Os | 2026-08-28 | N/A |
| An out-of-bounds read vulnerability in the WatchGuard Fireware OS iked process allows a remote unauthenticated attacker to create a Denial of Service (DoS) condition in VPN processing by sending specially crafted network traffic. | ||||
| CVE-2026-81851 | 1 Watchguard | 1 Fireware Os | 2026-08-28 | N/A |
| A heap-based buffer overflow vulnerability in Fireware OS's iked process allows an authenticated administrator to crash the IKE daemon (iked), resulting in a denial of service, by saving a specially crafted configuration. | ||||
| CVE-2026-80698 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix double free of wq, engine, and group structs The release callbacks for wq, engine, and group devices (idxd_conf_wq_release, idxd_conf_engine_release, idxd_conf_group_release) each call kfree() on the enclosing struct. The setup error paths and cleanup functions also call kfree() explicitly after put_device(), producing a double free whenever put_device() drops the reference count to zero and fires the release. In the setup functions, device_initialize() is called before device_add(), so the reference count is exactly 1 at the error sites. put_device() unconditionally fires the release, which frees the struct; the subsequent explicit kfree() then operates on freed memory. For idxd_setup_wqs(), the wq release callback also owns opcap_bmap and wqcfg. The error unwind additionally freed those fields explicitly before calling put_device(), causing further double frees on both. Remove the redundant explicit kfree() calls from all setup error paths and cleanup functions for wq, engine, and group structs, delegating sole ownership of those allocations to the release callbacks. | ||||
| CVE-2026-48417 | 1 Adobe | 1 Substance 3d Sampler | 2026-08-28 | 7.8 High |
| Substance3D - Sampler is affected by a Stack-based Buffer Overflow vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-80701 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: enforce cursor size limits for MOB cursors vmw_cursor_plane_atomic_check() bounds cursor width and height only on the legacy update path; the SVGA_CAP2_CURSOR_MOB path -- the default on modern hosts -- accepts any size. When the requested size exceeds SVGA_REG_CURSOR_MAX_DIMENSION or SVGA_REG_MOB_MAX_SIZE, vmw_cursor_mob_get() returns -EINVAL and leaves vps->cursor.mob NULL. Its return value is then discarded in vmw_cursor_plane_prepare_fb(), so the subsequent vmw_cursor_update_mob() calls vmw_bo_map_and_cache(NULL) and oopses inside vmw_bo_map_and_cache_size() on the tbo.base.size load. Reachable from any DRM master via DRM_IOCTL_MODE_CURSOR2 with a sufficiently large width or height (e.g. cursor_max_dim + 1). Reject oversized cursors in atomic_check for both MOB-backed cursor update types. The MOB byte-size limit only applies to the SVGA_CAP2_CURSOR_MOB path (vmw_cursor_mob_size() returns 0 for GB_ONLY); compute the required MOB size in 64-bit to avoid overflow when very large dimensions are requested. In prepare_fb only call vmw_cursor_mob_get()/_map() for VMW_CURSOR_UPDATE_MOB -- the GB_ONLY path uses bo->map.virtual directly and would otherwise be silently downgraded to NONE on hosts without SVGA_CAP2_CURSOR_MOB (where vmw_cursor_mob_get() always returns -EINVAL). Degrade the update to NONE if vmw_cursor_mob_get() or vmw_cursor_mob_map() fails so the update path does not run with a NULL backing MOB. | ||||
| CVE-2026-80699 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Avoid double-deactivate of IRQs in the nested context In the nested state, the physical interrupt has already been deactivated through the HW bit in the LR. The extra deactivation would be harmless but can hit an errata case on AmpereOne, so avoid it here. On AmpereOne, deactivating a physical interrupt through ICC_DIR_EL1 or ICC_EOIR1_EL1 (depending on EOImode) which is not active, but is the highest priority pending interrupt causes the cpu to lose the interrupt pending state and also prevents the delivery of future interrupts. | ||||
| CVE-2026-73576 | 2 Synacor, Zimbra | 2 Zimbra Collaboration Suite, Collaboration | 2026-08-28 | 6.3 Medium |
| In Zimbra Collaboration (ZCS) before 10.1.17, weak cryptographic key generation vulnerability exists in the OnlyOffice integration. The zimbraDocumentEditingJwtSecret is generated using an insecure random number generator, resulting in insufficient entropy. An attacker who obtains a JWT signed with the generated secret may be able to recover the JWT signing secret through offline brute-force, potentially enabling JWT forgery. | ||||
| CVE-2026-53362 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check. | ||||
| CVE-2026-80640 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: cxl/fwctl: Fix __fortify_panic Fix a runtime assertion in cxlctl_get_supported_features(). Fortify complains that it is potentially overflowing the entries array per __counted_by_le(num_entries). Quiet the false positive by initializing @num_entries earlier. memcpy: detected buffer overflow: 48 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#7: fwctl/1398 RIP: 0010:__fortify_report+0x50/0xa0 Call Trace: __fortify_panic+0xd/0xf cxlctl_get_supported_features.cold+0x23/0x35 [cxl_core] | ||||
| CVE-2026-80595 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - add response length checks The driver processes response data from device buffers without verifying that the device actually sent enough data. This can lead to out-of-bounds reads or processing stale data. Add checks for the expected response length before accessing the buffers. | ||||
| CVE-2026-82250 | 1 Gitoxidelabs | 1 Gitoxide | 2026-08-28 | 6.5 Medium |
| gitoxide gix-packetline versions before 0.21.5 contain a panic vulnerability in the TextRef implementation that occurs when processing side-band packet lines with empty payloads. A malicious Git server can send a crafted side-band packet to trigger an index out of bounds panic, aborting the client process during fetch operations without authentication. | ||||
| CVE-2026-80557 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: libceph: fix OOB read in decode_watchers() via missing bounds check ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ] | ||||
| CVE-2026-80558 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: libceph: Avoid using invalid osd indices from primary_temp A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts that don't exist, i.e., that are greater than max_osd or smaller than CEPH_HOMELESS_OSD (-1). These indices are used to create the up and acting set in ceph_pg_to_up_acting_osds(), called from calc_target(). While most of these osd indices are checked, the one from primary_temp is not. Subsequently, this may lead to calc_target() returning this (potentially invalid) index as target osd for a (linger) request. Because the osd_state, osd_weight, and osd_addr arrays only contain max_osd entries (with indices 0 to max_osd -1), this leads to out-of-bounds accesses when trying to read values from these arrays. This patch fixes the issue by adding a check to get_temp_osds(), so that only valid osd indices from primary_temp are used, and it falls back to using the primary from pg_temp or the up set if it is invalid. [ idryomov: changelog ] | ||||
| CVE-2026-80560 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: openrisc: signal: do not restore privileged SR bits on sigreturn restore_sigcontext() copies the whole supervision register (SR) from the signal frame and only clears SPR_SR_SM before the value is reloaded into the hardware SR (through ESR and l.rfe) on the return to user space. All other SR bits are left under user control. An unprivileged task can thus return from a signal handler through a crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the CPU performs no translation or protection on data accesses, so the task gains read and write access to arbitrary physical memory, a local privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH and the cache-enable bits are exposed the same way. The ptrace GPR regset already refuses any change to SR for exactly this reason. Restore only the arithmetic flag bits (F, CY, OV) from the signal frame and take every privileged control bit from the SR the kernel saved on signal entry. Verified with qemu-system-or1k -M or1k-sim: before this change an unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the same PoC receives SIGSEGV and physical memory is unchanged. | ||||
| CVE-2026-74744 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: ipvlan: inherit needed_headroom and needed_tailroom from phy_dev ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying phy_dev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. | ||||
| CVE-2026-59298 | 1 Spring | 1 Spring Cloud Function | 2026-08-28 | 3.1 Low |
| Potential for improper filtering of HTTP headers in Spring Cloud Function. Spring Cloud Function 5.0.0 - 5.0.3 Spring Cloud Function 4.3.0 - 4.3.4 Spring Cloud Function 4.2.0 - 4.2.7 Spring Cloud Function 3.2.16 and earlier | ||||
| CVE-2026-74751 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 9.4 Critical |
| In the Linux kernel, the following vulnerability has been resolved: riscv: lib: Fix ZBB strnlen reading past count boundary The ZBB-optimized strnlen loop loads one word ahead before checking the aligned boundary: REG_L t1, SZREG(t0) // load next word addi t0, t0, SZREG // advance orc.b t1, t1 bgeu t0, t4, 4f // boundary check AFTER load where t4 = (s + count) & -SZREG. When s is aligned and count is a multiple of SZREG, t4 equals s + count and the loop loads a full word starting at exactly s + count. If s + count falls on a page boundary with the next page unmapped, this faults. Fix by computing the aligned boundary from the last valid byte (s + count - 1) instead of s + count. This makes the loop stop at the word containing the last valid byte rather than potentially loading the word after it. The count == 0 case is already handled by the beqz early exit. Also add a pre-loop guard (bgeu t0, t4) for the case where all valid bytes fit within the first word. With the adjusted boundary, t4 can equal t0, and entering the loop with stale register state from the first-word processing would produce incorrect results. The final minu clamp ensures the result is still correct when the last loaded word extends past s + count - 1 within the same aligned word. | ||||