Export limit exceeded: 360533 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (360533 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-52945 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Revert "wireguard: device: enable threaded NAPI" This reverts commit 933466fc50a8e4eb167acbd0d8ec96a078462e9c which is commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e upstream. We have had three independent production user reports in combination with Cilium utilizing WireGuard as encryption underneath that k8s Pod E/W traffic to certain peer nodes fully stalled. The situation appears as follows: - Occurs very rarely but at random times under heavy networking load. - Once the issue triggers the decryption side stops working completely for that WireGuard peer, other peers keep working fine. The stall happens also for newly initiated connections towards that particular WireGuard peer. - Only the decryption side is affected, never the encryption side. - Once it triggers, it never recovers and remains in this state, the CPU/mem on that node looks normal, no leak, busy loop or crash. - bpftrace on the affected system shows that wg_prev_queue_enqueue fails, thus the MAX_QUEUED_PACKETS (1024 skbs!) for the peer's rx_queue is reached. - Also, bpftrace shows that wg_packet_rx_poll for that peer is never called again after reaching this state for that peer. For other peers wg_packet_rx_poll does get called normally. - Commit db9ae3b ("wireguard: device: enable threaded NAPI") switched WireGuard to threaded NAPI by default. The default has not been changed for triggering the issue, neither did CPU hotplugging occur (i.e. 5bd8de2 ("wireguard: queueing: always return valid online CPU in wg_cpumask_choose_online()")). - The issue has been observed with stable kernels of v5.15 as well as v6.1. It was reported to us that v5.10 stable is working fine, and no report on v6.6 stable either (somewhat related discussion in [0] though). - In the WireGuard driver the only material difference between v5.10 stable and v5.15 stable is the switch to threaded NAPI by default. [0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/ Breakdown of the problem: 1) skbs arriving for decryption are enqueued to the peer->rx_queue in wg_packet_consume_data via wg_queue_enqueue_per_device_and_peer. 2) The latter only moves the skb into the MPSC peer queue if it does not surpass MAX_QUEUED_PACKETS (1024) which is kept track in an atomic counter via wg_prev_queue_enqueue. 3) In case enqueueing was successful, the skb is also queued up in the device queue, round-robin picks a next online CPU, and schedules the decryption worker. 4) The wg_packet_decrypt_worker, once scheduled, picks these up from the queue, decrypts the packets and once done calls into wg_queue_enqueue_per_peer_rx. 5) The latter updates the state to PACKET_STATE_CRYPTED on success and calls napi_schedule on the per peer->napi instance. 6) NAPI then polls via wg_packet_rx_poll. wg_prev_queue_peek checks on the peer->rx_queue. It will wg_prev_queue_dequeue if the queue->peeked skb was not cached yet, or just return the latter otherwise. (wg_prev_queue_drop_peeked later clears the cache.) 7) From an ordering perspective, the peer->rx_queue has skbs in order while the device queue with the per-CPU worker threads from a global ordering PoV can finish the decryption and signal the skb PACKET_STATE_CRYPTED out of order. 8) A situation can be observed that the first packet coming in will be stuck waiting for the decryption worker to be scheduled for a longer time when the system is under pressure. 9) While this is the case, the other CPUs in the meantime finish decryption and call into napi_schedule. 10) Now in wg_packet_rx_poll it picks up the first in-order skb from the peer->rx_queue and sees that its state is still PACKET_STATE_UNCRYPTED. The NAPI poll routine then exits e ---truncated--- | ||||
| CVE-2026-52950 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe/dma-buf: fix UAF with retry loop Retry doesn't work here, since bo will be freed on error, leading to UAF. However, now that we do the alloc & init before the attach, we can now combine this as one unit and have the init do the alloc for us. This should make the retry safe. Reported by Sashiko. v2: Fix up the error unwind (CI) (cherry picked from commit 479669418253e0f27f8cf5db01a731352ea592e7) | ||||
| CVE-2026-52953 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix oops due to out of scope access Below oops triggers when kill QEMU process: Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI Call Trace: <TASK> do_raw_spin_lock+0xaa/0xc0 _raw_spin_lock_irqsave+0x21/0x40 domain_remove_dev_pasid+0x52/0x160 intel_nested_set_dev_pasid+0x1b9/0x1e0 __iommu_set_group_pasid+0x56/0x120 pci_dev_reset_iommu_done+0xe3/0x180 pcie_flr+0x65/0x160 __pci_reset_function_locked+0x5b/0x120 vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core] vfio_df_close+0x4f/0xa0 vfio_df_unbind_iommufd+0x2d/0x60 vfio_device_fops_release+0x3e/0x40 __fput+0xe5/0x2c0 task_work_run+0x58/0xa0 do_exit+0x2c8/0x600 do_group_exit+0x2f/0xa0 get_signal+0x863/0x8c0 arch_do_signal_or_restart+0x24/0x100 exit_to_user_mode_loop+0x87/0x380 do_syscall_64+0x2ff/0x11e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The global static blocked domain is a dummy domain without corresponding dmar_domain structure, accessing beyond iommu_domain structure triggers oops easily. Fix it by return early in domain_remove_dev_pasid() like identity domain. | ||||
| CVE-2026-52958 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in osdmap_decode() When decoding osd_state and osd_weight from an incoming osdmap in osdmap_decode(), both are decoded for each osd, i.e., map->max_osd times. The ceph_decode_need() check only accounts for sizeof(*map->osd_weight) once. This can potentially result in an out-of-bounds memory access if the incoming message is corrupted such that the max_osd value exceeds the actual content of the osdmap message. This patch fixes the issue by changing the corresponding part in the ceph_decode_need() check to account for map->max_osd*sizeof(*map->osd_weight). | ||||
| CVE-2026-52962 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ceph: fix a buffer leak in __ceph_setxattr() The old_blob in __ceph_setxattr() can store ci->i_xattrs.prealloc_blob value during the retry. However, it is never called the ceph_buffer_put() for the old_blob object. This patch fixes the issue of the buffer leak. | ||||
| CVE-2026-52963 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Bound MIDI endpoint descriptor scans snd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint descriptor size before using baAssocJackID[], but the descriptor walker can still return a class-specific endpoint descriptor whose bLength exceeds the remaining bytes in the endpoint-extra scan. That leaves later flexible-array reads bounded by bLength, but not by the remaining bytes in the endpoint-extra scan. Stop walking when bLength is zero or extends past the remaining endpoint-extra scan. | ||||
| CVE-2026-52965 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure When ttm_tt_swapout() fails, the current code calls ttm_resource_add_bulk_move() followed by ttm_resource_move_to_lru_tail() to restore the resource's bulk_move membership. However, ttm_resource_move_to_lru_tail() places the resource at the tail of the LRU list which, relative to the walk cursor's hitch node (placed immediately after the resource when it was yielded), puts the resource *in front of the* the hitch. The next list_for_each_entry_continue() from the hitch finds the same resource again, causing an infinite loop. Fix by deferring del_bulk_move to the success path only. On the success path, TTM_TT_FLAG_SWAPPED has just been set by ttm_tt_swapout() but the resource is still tracked in the bulk_move range, so ttm_resource_del_bulk_move()'s !ttm_resource_unevictable() guard would incorrectly skip the removal. Introduce ttm_resource_del_bulk_move_unevictable() which bypasses that guard. | ||||
| CVE-2026-52966 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm: Replace old pointer to new idr Commit 5e28b7b94408 introduced a logical error by failing to replace the newly generated IDR pointer to old id's pointer at the correct location within the "change handle" logic; this resulted in the issue reported by syzbot [1]. Specifically, the new IDR object pointer is intended to replace the original id's pointer during the normal execution flow. Additionally, an unnecessary conditional check for the ret exit path has been removed. [1] !RB_EMPTY_ROOT(&prime_fpriv->dmabufs) WARNING: drivers/gpu/drm/drm_prime.c:224 at drm_prime_destroy_file_private+0x48/0x60 drivers/gpu/drm/drm_prime.c:224, CPU#0: syz.0.17/5833 Call Trace: drm_file_free.part.0+0x7e6/0xcc0 drivers/gpu/drm/drm_file.c:269 drm_file_free drivers/gpu/drm/drm_file.c:237 [inline] drm_close_helper.isra.0+0x186/0x200 drivers/gpu/drm/drm_file.c:290 drm_release+0x1ab/0x360 drivers/gpu/drm/drm_file.c:438 | ||||
| CVE-2026-52968 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetic kvm_s390_pci_aif_enable(), kvm_s390_pci_aif_disable(), and aen_host_forward() index the GAIT by manually multiplying the index with sizeof(struct zpci_gaite). Since aift->gait is already a struct zpci_gaite pointer, this double-scales the offset, accessing element aisb*16 instead of aisb. This causes out-of-bounds accesses when aisb >= 32 (with ZPCI_NR_DEVICES=512) Fix by removing the erroneous sizeof multiplication. | ||||
| CVE-2026-52969 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: KVM: Reject wrapped offset in kvm_reset_dirty_gfn() kvm_reset_dirty_gfn() guards the gfn range with if (!memslot || (offset + __fls(mask)) >= memslot->npages) return; but offset is u64 and the addition is unchecked. The check can be silently bypassed by a u64 wrap. The dirty ring backing those entries is MAP_SHARED at KVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the slot and offset fields of any entry between when the kernel pushes them and when KVM_RESET_DIRTY_RINGS consumes them. On reset, kvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds them straight back into this check; only the flags handshake is treated as the handover, the slot/offset payload is taken on trust. Crafting two entries entry[i].offset = 0xffffffffffffffc1 entry[i+1].offset = 0 makes the coalescing loop in kvm_dirty_ring_reset() compute delta = (s64)(0 - 0xffffffffffffffc1) = 63 which falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the existing mask by setting bit 63. The trailing kvm_reset_dirty_gfn() call then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63; the sum is 0 in u64 and the bounds check passes. That offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked() unchanged. On the legacy MMU path -- kvm_memslots_have_rmaps() == true, i.e. shadow paging, any VM that has allocated shadow roots, or a write-tracked slot -- it reaches gfn_to_rmap(), which indexes slot->arch.rmap[0][] with a near-U64_MAX gfn. That is an out-of-bounds load of a kvm_rmap_head, followed by a conditional clear of PT_WRITABLE_MASK in whatever the loaded pointer points at. The path is reachable from any process holding /dev/kvm. Range-check offset on its own first, so the addition cannot wrap. memslot->npages is bounded well below U64_MAX, so once offset < npages holds, offset + __fls(mask) (with __fls(mask) < BITS_PER_LONG) stays in range. | ||||
| CVE-2026-49220 | 2026-06-24 | 5.7 Medium | ||
| Jellyfin is an open source self hosted media server. Prior to 10.11.9, a potential XSS attack exists in Jellyfin which can allow a non-privileged user to execute arbitrary Javascript in the context of a logged-in Administrative user, resulting in numerous potential issues. The Client header during an AuthenticateByName can contain arbitrary HTML and Javascript, which will then be executed by the Administrative user when visiting the Access tab of the user in question from within the dashboard. This vulnerability is fixed in 10.11.9. | ||||
| CVE-2026-48793 | 2026-06-24 | 8.8 High | ||
| Jellyfin is an open source self hosted media server. Prior to 10.11.10, a potential FFmpeg argument injection vulnerability exists in the subtitle conversion code path. SubtitleEncoder.ConvertTextSubtitleToSrtInternal (SubtitleEncoder.cs, line 382) interpolates the subtitle file path into FFmpeg command-line arguments without calling EncodingUtils.NormalizePath(). On Linux, filenames can contain double-quote characters, which break the argument quoting and allow injection of arbitrary FFmpeg arguments. The vulnerability is reachable without authentication via SubtitleController.GetSubtitle, which has no [Authorize] attribute. An attacker who can place a file in a Jellyfin media library directory (shared NAS, Samba share, guest upload) can achieve arbitrary file write on the server and information disclosure. This vulnerability is fixed in 10.11.10. | ||||
| CVE-2026-49246 | 2026-06-24 | N/A | ||
| Jellyfin is an open source self hosted media server. Prior to 10.11.10, a specifically crafted MKV file containing forged filename tags can be leveraged to exploit missing path sanitization during playback. Jellyfin treats the MKV file name tag on MKV attachments as trusted and passes it unsanitized into Path.Combine(attachmentFolder, fileName) inside PathManager.GetAttachmentPath. Because .NET's Path.Combine neither normalises .. nor rejects a rooted second argument, a crafted MKV can redirect Jellyfin's MKV attachment extraction to any absolute path on disk. This triggers on any playback action of the affected video on a client which will attempt to burn in the subtitles by default.g This vulnerability is fixed in 10.11.10. | ||||
| CVE-2026-49247 | 2026-06-24 | 8.8 High | ||
| Jellyfin is an open source self hosted media server. From 10.9.0 until 10.11.10, the POST /ClientLog/Document endpoint accepts the Authorization header's Client and Version fields and uses them unsanitized as components of the on-disk filename when persisting client-uploaded log documents. As a result, any authenticated non-admin user can include ../ sequences in the Client field to cause Jellyfin to write attacker-controlled content to arbitrary paths reachable by the Jellyfin service user, with a forced .log suffix. This vulnerability is fixed in 10.11.10. | ||||
| CVE-2026-12986 | 1 Payara | 1 Payara Server | 2026-06-24 | N/A |
| A critical vulnerability in Admin GUI in Payara Server Full 4.x, 5.x, 6.x, 7.x, 7.2026.x, 6.2025.x, 6.2024.x on All platforms that allows the attacker to leak the admin gfresttoken to an attacker-controlled host that can result in a full unauthenticated takeover of Payara admin domain. A Server-Side Request Forgery (SSRF) vulnerability in the DownloadServlet of the Admin GUI in Payara Server allows a remote attacker to exfiltrate the administrator's REST session token (gfresttoken) to an attacker-controlled host via a crafted request URL. Combined with the absence of CSRF protection on DownloadServlet, an unauthenticated attacker can trick a logged-in administrator into triggering the token leak, then replay the stolen token to gain full administrative access to the Payara domain, leading to arbitrary code execution via WAR deployment. The vulnerability exists in the DownloadServlet and associated ContentSource implementations (LogViewerContentSource, LogFilesContentSource, LBConfigContentSource, ClientStubsContentSource) within the admingui:console-common module. | ||||
| CVE-2026-53943 | 2026-06-24 | 9.6 Critical | ||
| Ghost is a Node.js content management system. From until 6.37.0, when Ghost is behind a shared caching layer that results in cached content being shared between different visitors, an unauthenticated user could send an x-ghost-preview header that altered the rendered frontend response. In affected cache configurations, that response could be stored and served to subsequent visitors requesting the same page, allowing cache poisoning of request-specific preview output. When running Ghost's frontend and admin panel on the same domain this could be used to take over staff user accounts. When running these on different domains staff accounts have no exposure. This vulnerability is fixed in 6.37.0. | ||||
| CVE-2026-12760 | 2026-06-24 | N/A | ||
| A denial-of-service (DoS) vulnerability has been identified in Tapo C200 v3 in the network packet handling logic due to improper handling of IPv4 fragmented packets. An unauthenticated adjacent attacker can send crafted packets to cause excessive resource consumption, leading to instability of the device.Successful exploitation can remotely trigger a temporary denial-of-service condition, causing the camera to become unresponsive and resulting in intermittent loss of video monitoring and recording. | ||||
| CVE-2026-53944 | 2026-06-24 | 5.8 Medium | ||
| Ghost is a Node.js content management system. From 6.0.9 until 6.21.1, when making an external request, it is possible to bypass the IP filter that ensures the request isn't going to an internal service using an IPv6 literal which maps to a private IPv4 address. This vulnerability is fixed in 6.21.1. | ||||
| CVE-2026-53945 | 2026-06-24 | 4 Medium | ||
| Ghost is a Node.js content management system. From 6.0.9 until 6.21.1, Ghost’s private-IP check for outbound HTTP requests could be bypassed via DNS rebinding, allowing an attacker to coerce the Ghost server into reaching hosts on internal networks through features that issue external fetches. This vulnerability is fixed in 6.21.1. | ||||
| CVE-2026-53946 | 2026-06-24 | 5.4 Medium | ||
| Ghost is a Node.js content management system. From 6.19.4 until 6.21.1, when re-rendering posts, Ghost would refetch missing image dimensions by issuing an outbound HTTP request to the URL stored on an image card — without restricting that URL to trusted image hosts. An authenticated staff user able to create or edit posts could therefore point an image card at an attacker-chosen host and cause the Ghost server to request it on their behalf, including hosts on internal networks or cloud instance metadata endpoints that would not normally be reachable from the public internet. This vulnerability is fixed in 6.21.1. | ||||