Export limit exceeded: 385751 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 385751 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (2312 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-18549 | 1 Fastify | 1 Fastify-multipart | 2026-08-17 | 7.5 High |
| @fastify/multipart is a multipart form-data parser for Fastify. In versions from 5.3.0 up to but not including 10.1.1, when the busboy fileSize limit truncates a file part, the plugin clears its internal current-file reference while the underlying stream is still open. If the client then aborts the connection before sending the terminating boundary, the abort cleanup finds no stream to destroy, so saveRequestFiles() never settles, the request handler hangs, and the temporary file already written to disk is never cleaned up. An unauthenticated client can repeat this to permanently leak temporary files and suspended handler executions, leading to disk and event-loop exhaustion. The issue is fixed in @fastify/multipart 10.1.1. Users should upgrade to 10.1.1. | ||||
| CVE-2026-72249 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage. | ||||
| CVE-2026-72358 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: prevent invalid cursor access for purged BOs During a page table walk for binding, xe_pt_stage_bind() explicitly skips initializing the xe_res_cursor for purged BOs, treating them similarly to NULL VMAs by only setting the cursor size. However, xe_pt_hugepte_possible() and xe_pt_scan_64K() did not check if the BO was purged before attempting to walk the cursor using xe_res_dma() and xe_res_next(). Because the cursor was left uninitialized for purged BOs, this falls through and triggers warnings like: WARNING: drivers/gpu/drm/xe/xe_res_cursor.h:274 at xe_res_next Fix this by explicitly checking if the BO is purged in both xe_pt_hugepte_possible() and xe_pt_scan_64K(), returning early just as we do for NULL VMAs, avoiding the invalid cursor accesses entirely. As a precaution, also zero-initialize the cursor in xe_pt_stage_bind() to ensure we don't pass garbage data into the page table walkers if we ever hit a similar edge case in the future. (cherry picked from commit 4c7b9c6ece32440e5a435a92076d049450cd2d2e) | ||||
| CVE-2026-75003 | 1 Roundcube | 1 Webmail | 2026-08-17 | 5.8 Medium |
| In Roundcube Webmail before 1.6.18 and 1.7.x before 1.7.3, an unclosed url() in a FuncIRI attribute of an SVG image could evade the remote image blocking, which may lead to information disclosure or privilege escalation. | ||||
| CVE-2026-75000 | 1 Roundcube | 1 Webmail | 2026-08-17 | 5.8 Medium |
| In Roundcube Webmail before 1.6.18 and 1.7.x before 1.7.3, improper HTML/CSS sanitization of the SVG animate "by" attribute may lead to remote image blocking bypass, which in turn may lead to information disclosure or privilege escalation. | ||||
| CVE-2026-75010 | 1 Roundcube | 1 Webmail | 2026-08-17 | 6.4 Medium |
| In Roundcube Webmail before 1.6.18 and 1.7.x before 1.7.3, the modoboa driver of the password plugin could leak a Modoboa API authentication token to a user-controlled host via crafted session data. This issue only affects Roundcube instances using the password plugin with its modoboa driver. | ||||
| CVE-2026-74355 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 8.2 High |
| In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix RB-tree corruption in probe error path The info->node RB-tree member is zero-initialized via kzalloc. If a device does not support ATS, the device_rbtree_insert() call is skipped. If a subsequent probe step fails, the error path jumps to device_rbtree_remove(), which misinterprets the zeroed node as a tree root and corrupts the device RB-tree. Fix this by explicitly initializing the RB-node as empty using RB_CLEAR_NODE() during initialization and guarding the removal with RB_EMPTY_NODE(). | ||||
| CVE-2026-74429 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix the reception of a reply packet before data transmission Fix rxrpc_receiving_reply() to handle the reception of an apparent reply DATA packet before rxrpc has had a chance to send any request DATA packets on a client call by checking to see if the call has been exposed yet by sending the first packet. Without this, rxrpc_rotate_tx_window() might oops. Also fix rxrpc_rotate_tx_window() to handle the Tx queue being empty by changing the do...while loop into a while loop, just in case a call is abnormally terminated by an early reply before the last request packet is transmitted. | ||||
| CVE-2026-72474 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor For architectures like Microblaze or arm64 (where this IP is used), DMA_DIRECT_REMAP is set which means that dma_alloc_coherent() might remap (and hence vmalloc()) some memory. This became visible in a design where dma_direct_use_pool() is not possible. With the above, when calling dma_free_coherent(), vunmap() would be called from softirq context and thus leading to a BUG(). To fix it, use a dma pool that is allocated in .device_alloc_chan_resources() and allocate blocks from it. The key point is that now dma_pool_free() is used in axi_dmac_free_desc() to free the blocks and that just frees the blocks from the pool in the sense they can be used again. In other words, no actual call to dma_free_coherent() happens. That only happens when destroying the pool in axi_dmac_free_chan_resources() which does not happen in any interrupt context. | ||||
| CVE-2026-72363 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfs: Fix folio state after ENOMEM whilst under writeback iteration Fix the state of the current folio when ENOMEM occurs during writeback iteration. The folio needs to be redirtied and unlocked before the terminal writeback_iter() is invoked. | ||||
| CVE-2026-72246 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-72047 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange a kmalloc'd buffer pointer through a struct kfifo, but pass a literal '4' as the byte count to kfifo_in()/kfifo_out(). This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the low 4 bytes of the 8-byte pointer are written into the FIFO. The reader then reads back 4 bytes into an 8-byte local pointer variable, leaving the upper 4 bytes uninitialized stack data. The first dereference of the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel address and generally results in an oops. Use sizeof(fifo_buffer) so the byte count matches pointer width on every architecture. The driver has no architecture restriction in Kconfig, so any 64-bit build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has been latent since the driver was added in 2017 because it is most commonly deployed on 32-bit MCUs. Found via a custom Coccinelle semantic patch hunting for short-byte kfifo I/O on byte-mode kfifos used to shuttle pointers. | ||||
| CVE-2026-20269 | 1 Cisco | 2 Ios Xe, Ios Xe Software | 2026-08-14 | 8.6 High |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco IOS XE Software engineering team has conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-20269 are related to issues with improper control of a resource through its lifetime that are grouped under the Common Weakness Enumeration (CWE) Pillar CWE-664. | ||||
| CVE-2026-20158 | 1 Cisco | 3 Roomos, Roomos Cloud, Roomos Software | 2026-08-14 | 7.5 High |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco RoomOS engineering team has conducted a comprehensive internal security review. This review resulted in a software hardening release that addresses multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-20158 are related to improper control of a resource through its lifetime that are grouped under the Common Weakness Enumeration (CWE) Pillar CWE-664. | ||||
| CVE-2026-73843 | 1 Openchoreo | 1 Openchoreo | 2026-08-14 | 9.6 Critical |
| OpenChoreo is a complete, open-source developer platform for Kubernetes. Prior to 1.0.2 and 1.1.2, internal/cluster-gateway/server.go served caller-facing management APIs on the externally reachable agent listener without authentication, allowing network-reachable attackers to invoke /api/proxy/ and /api/exec/ operations, proxy the data-plane Kubernetes API, and execute commands in workload pods in multi-cluster deployments. This issue is fixed in versions 1.0.2 and 1.1.2. | ||||
| CVE-2025-34226 | 1 Openplcproject | 2 Openplc, Openplc V3 | 2026-08-14 | N/A |
| OpenPLC Runtime v3 contains an input validation flaw in the /upload-program-action endpoint: the epoch_time field supplied during program uploads is not validated and can be crafted to induce corruption of the programs database. After a successful malformed upload the runtime continues to operate until a restart; on restart the runtime can fail to start because of corrupted database entries, resulting in persistent denial of service requiring complete rebase of the product to recover. This vulnerability was remediated by commit 095ee09. | ||||
| CVE-2026-24708 | 1 Openstack | 2 Compute, Nova | 2026-08-14 | 8.2 High |
| An issue was discovered in OpenStack Nova before 30.2.2, 31 before 31.2.1, and 32 before 32.1.1. By writing a malicious QCOW header to a root or ephemeral disk and then triggering a resize, a user may convince Nova's Flat image backend to call qemu-img without a format restriction, resulting in an unsafe image resize operation that could destroy data on the host system. Only compute nodes using the Flat image backend (usually configured with use_cow_images=False) are affected. | ||||
| CVE-2025-71315 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/vkms: Convert to DRM's vblank timer Replace vkms' vblank timer with the DRM implementation. The DRM code is identical in concept, but differs in implementation. Vblank timers are covered in vblank helpers and initializer macros, so remove the corresponding hrtimer in struct vkms_output. The vblank timer calls vkms' custom timeout code via handle_vblank_timeout in struct drm_crtc_helper_funcs. | ||||
| CVE-2026-12233 | 1 Zephyrproject | 1 Zephyr | 2026-08-13 | 5.9 Medium |
| The PSA Protected Storage credential backend (subsys/net/lib/tls_credentials/tls_credentials_trusted.c) declared its credential-store mutex as a plain zero-filled static struct k_mutex credential_lock; and never called k_mutex_init() on it. A statically zero-filled k_mutex has an uninitialized wait queue (its dlist head/tail are NULL instead of the self-referential sentinels that k_mutex_init/K_MUTEX_DEFINE install). The uncontended lock path does not touch the wait queue, so the defect is latent and serialized use behaves correctly. When two execution contexts contend on the lock, k_mutex_lock() pends the blocking thread on the wait queue via z_pend_curr(), which calls sys_dlist_append() on the zeroed list and dereferences a NULL tail pointer (tail->next = node), faulting the kernel. The lock is held during TLS handshake credential loading and by all credential add/get/delete operations, so a deployment performing concurrent TLS handshakes (for example a server handling multiple simultaneous connections from a remote peer) or a credential-management operation concurrent with a handshake can trigger the dereference. The impact is a denial of service: a deterministic kernel panic / device reset on the first contention. There is no memory corruption beyond the NULL dereference and no confidentiality or integrity impact; mutual exclusion on the fast path remains correct. Exposure is limited to builds with CONFIG_TLS_CREDENTIALS_BACKEND_PROTECTED_STORAGE enabled (PSA Protected Storage / TF-M platforms); the default volatile RAM backend initializes its lock correctly and is unaffected. The fix initializes the mutex statically with K_MUTEX_DEFINE(credential_lock), providing a valid wait queue so the contended path no longer touches a NULL list. | ||||
| CVE-2026-64164 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: tracepoints: fix sleep while in atomic context in btrfs_sync_file() The trace event btrfs_sync_file() is called in an atomic context (all trace events are) and its call to dput(), which is needed due to the call to dget_parent(), can sleep, triggering a kernel splat. This can be reproduced by enabling the trace event and running btrfs/056 from fstests for example. The splat shown in dmesg is the following: [53.919] BUG: sleeping function called from invalid context at fs/dcache.c:970 [53.947] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 32773, name: xfs_io [53.988] preempt_count: 2, expected: 0 [53.967] RCU nest depth: 0, expected: 0 [53.943] Preemption disabled at: [53.944] [<0000000000000000>] 0x0 [54.078] CPU: 0 UID: 0 PID: 32773 Comm: xfs_io Tainted: G W 7.1.0-rc1-btrfs-next-232+ #1 PREEMPT(full) [54.070] Tainted: [W]=WARN [54.071] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [54.072] Call Trace: [54.074] <TASK> [54.076] dump_stack_lvl+0x56/0x80 [54.079] __might_resched.cold+0xd6/0x10f [54.072] dput.part.0+0x24/0x110 [54.078] trace_event_raw_event_btrfs_sync_file+0x75/0x140 [btrfs] [54.089] btrfs_sync_file+0x1ed/0x530 [btrfs] [54.087] ? __handle_mm_fault+0x8ae/0xed0 [54.089] btrfs_do_write_iter+0x172/0x210 [btrfs] [54.091] vfs_write+0x21f/0x450 [54.094] __x64_sys_pwrite64+0x8d/0xc0 [54.096] ? do_user_addr_fault+0x20c/0x670 [54.099] do_syscall_64+0x60/0xf20 [54.092] ? clear_bhb_loop+0x60/0xb0 [54.094] entry_SYSCALL_64_after_hwframe+0x76/0x7e So stop using dget_parent() and dput() and access the parent dentry directly as dentry->d_parent. This is also what ext4 is doing in its equivalent trace event ext4_sync_file_enter(). | ||||