Export limit exceeded: 346800 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (346800 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-31658 | 1 Linux | 1 Linux Kernel | 2026-04-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb. | ||||
| CVE-2026-31660 | 1 Linux | 1 Linux Kernel | 2026-04-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: allocate rx skb before consuming bytes pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted. | ||||
| CVE-2026-31661 | 1 Linux | 1 Linux Kernel | 2026-04-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: Fix dma_free_coherent() size dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size. | ||||
| CVE-2026-31542 | 1 Linux | 1 Linux Kernel | 2026-04-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/platform/uv: Handle deconfigured sockets When a socket is deconfigured, it's mapped to SOCK_EMPTY (0xffff). This causes a panic while allocating UV hub info structures. Fix this by using NUMA_NO_NODE, allowing UV hub info structures to be allocated on valid nodes. | ||||
| CVE-2026-31565 | 1 Linux | 1 Linux Kernel | 2026-04-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix deadlock during netdev reset with active connections Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering device_delete and subsequent client removal. During client removal, uverbs_client waits for QP reference count to reach zero while cma_client holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock. | ||||
| CVE-2026-31571 | 1 Linux | 1 Linux Kernel | 2026-04-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/i915: Unlink NV12 planes earlier unlink_nv12_plane() will clobber parts of the plane state potentially already set up by plane_atomic_check(), so we must make sure not to call the two in the wrong order. The problem happens when a plane previously selected as a Y plane is now configured as a normal plane by user space. plane_atomic_check() will first compute the proper plane state based on the userspace request, and unlink_nv12_plane() later clears some of the state. This used to work on account of unlink_nv12_plane() skipping the state clearing based on the plane visibility. But I removed that check, thinking it was an impossible situation. Now when that situation happens unlink_nv12_plane() will just WARN and proceed to clobber the state. Rather than reverting to the old way of doing things, I think it's more clear if we unlink the NV12 planes before we even compute the new plane state. (cherry picked from commit 017ecd04985573eeeb0745fa2c23896fb22ee0cc) | ||||
| CVE-2026-31535 | 1 Linux | 1 Linux Kernel | 2026-04-24 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: make use of smbdirect_socket.recv_io.credits.available The logic off managing recv credits by counting posted recv_io and granted credits is racy. That's because the peer might already consumed a credit, but between receiving the incoming recv at the hardware and processing the completion in the 'recv_done' functions we likely have a window where we grant credits, which don't really exist. So we better have a decicated counter for the available credits, which will be incremented when we posted new recv buffers and drained when we grant the credits to the peer. | ||||
| CVE-2026-31547 | 1 Linux | 1 Linux Kernel | 2026-04-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix missing runtime PM reference in ccs_mode_store ccs_mode_store() calls xe_gt_reset() which internally invokes xe_pm_runtime_get_noresume(). That function requires the caller to already hold an outer runtime PM reference and warns if none is held: [46.891177] xe 0000:03:00.0: [drm] Missing outer runtime PM protection [46.891178] WARNING: drivers/gpu/drm/xe/xe_pm.c:885 at xe_pm_runtime_get_noresume+0x8b/0xc0 Fix this by protecting xe_gt_reset() with the scope-based guard(xe_pm_runtime)(xe), which is the preferred form when the reference lifetime matches a single scope. v2: - Use scope-based guard(xe_pm_runtime)(xe) (Shuicheng) - Update commit message accordingly (cherry picked from commit 7937ea733f79b3f25e802a0c8360bf7423856f36) | ||||
| CVE-2026-31561 | 1 Linux | 1 Linux Kernel | 2026-04-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/cpu: Remove X86_CR4_FRED from the CR4 pinned bits mask Commit in Fixes added the FRED CR4 bit to the CR4 pinned bits mask so that whenever something else modifies CR4, that bit remains set. Which in itself is a perfectly fine idea. However, there's an issue when during boot FRED is initialized: first on the BSP and later on the APs. Thus, there's a window in time when exceptions cannot be handled. This becomes particularly nasty when running as SEV-{ES,SNP} or TDX guests which, when they manage to trigger exceptions during that short window described above, triple fault due to FRED MSRs not being set up yet. See Link tag below for a much more detailed explanation of the situation. So, as a result, the commit in that Link URL tried to address this shortcoming by temporarily disabling CR4 pinning when an AP is not online yet. However, that is a problem in itself because in this case, an attack on the kernel needs to only modify the online bit - a single bit in RW memory - and then disable CR4 pinning and then disable SM*P, leading to more and worse things to happen to the system. So, instead, remove the FRED bit from the CR4 pinning mask, thus obviating the need to temporarily disable CR4 pinning. If someone manages to disable FRED when poking at CR4, then idt_invalidate() would make sure the system would crash'n'burn on the first exception triggered, which is a much better outcome security-wise. | ||||
| CVE-2026-31566 | 1 Linux | 1 Linux Kernel | 2026-04-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib amdgpu_amdkfd_submit_ib() submits a GPU job and gets a fence from amdgpu_ib_schedule(). This fence is used to wait for job completion. Currently, the code drops the fence reference using dma_fence_put() before calling dma_fence_wait(). If dma_fence_put() releases the last reference, the fence may be freed before dma_fence_wait() is called. This can lead to a use-after-free. Fix this by waiting on the fence first and releasing the reference only after dma_fence_wait() completes. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:697 amdgpu_amdkfd_submit_ib() warn: passing freed memory 'f' (line 696) (cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482) | ||||
| CVE-2026-31642 | 1 Linux | 1 Linux Kernel | 2026-04-24 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call removal to use RCU safe deletion Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs. | ||||
| CVE-2026-31650 | 1 Linux | 1 Linux Kernel | 2026-04-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix use-after-free on disconnect The vub300 driver maintains an explicit reference count for the controller and its driver data and the last reference can in theory be dropped after the driver has been unbound. This specifically means that the controller allocation must not be device managed as that can lead to use-after-free. Note that the lifetime is currently also incorrectly tied the parent USB device rather than interface, which can lead to memory leaks if the driver is unbound without its device being physically disconnected (e.g. on probe deferral). Fix both issues by reverting to non-managed allocation of the controller. | ||||
| CVE-2026-31653 | 1 Linux | 1 Linux Kernel | 2026-04-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: dealloc repeat_call_control if damon_call() fails damon_call() for repeat_call_control of DAMON_SYSFS could fail if somehow the kdamond is stopped before the damon_call(). It could happen, for example, when te damon context was made for monitroing of a virtual address processes, and the process is terminated immediately, before the damon_call() invocation. In the case, the dyanmically allocated repeat_call_control is not deallocated and leaked. Fix the leak by deallocating the repeat_call_control under the damon_call() failure. This issue is discovered by sashiko [1]. | ||||
| CVE-2026-31657 | 1 Linux | 1 Linux Kernel | 2026-04-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. The netlink claim dump path dereferences claim->backbone_gw->orig and takes claim->backbone_gw->crc_lock without pinning the underlying backbone gateway. batadv_bla_check_claim() still has the same naked pointer access pattern. Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate on a stable gateway reference until the read-side work is complete. This keeps the dump and claim-check paths aligned with the lifetime rules introduced for the other BLA claim readers. | ||||
| CVE-2026-39380 | 1 Opensourcepos | 2 Open Source Point Of Sale, Opensourcepos | 2026-04-24 | 5.4 Medium |
| Open Source Point of Sale is a web based point-of-sale application written in PHP using CodeIgniter framework. Prior to 3.4.3, a Stored Cross-Site Scripting (XSS) vulnerability exists in the Stock Locations configuration feature. The application fails to properly sanitize user input supplied through the stock_location parameter, allowing attackers to inject malicious JavaScript code that is stored in the database and executed when rendered in the Employees interface. This vulnerability is fixed in 3.4.3. | ||||
| CVE-2026-34078 | 1 Flatpak | 1 Flatpak | 2026-04-24 | 10.0 Critical |
| Flatpak is a Linux application sandboxing and distribution framework. Prior to 1.16.4, the Flatpak portal accepts paths in the sandbox-expose options which can be app-controlled symlinks pointing at arbitrary paths. Flatpak run mounts the resolved host path in the sandbox. This gives apps access to all host files and can be used as a primitive to gain code execution in the host context. This vulnerability is fixed in 1.16.4. | ||||
| CVE-2025-69394 | 2 Cnvrse, Wordpress | 2 Cnvrse, Wordpress | 2026-04-24 | 7.5 High |
| Authorization Bypass Through User-Controlled Key vulnerability in cnvrse Cnvrse cnvrse allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Cnvrse: from n/a through < 026.02.10.20. | ||||
| CVE-2025-69401 | 2 Mdalabar, Wordpress | 2 Wooodt Lite, Wordpress | 2026-04-24 | 7.5 High |
| Authentication Bypass by Spoofing vulnerability in mdalabar WooODT Lite byconsole-woo-order-delivery-time allows Identity Spoofing.This issue affects WooODT Lite: from n/a through <= 2.5.2. | ||||
| CVE-2026-22341 | 2 Case-themes, Wordpress | 2 Booked, Wordpress | 2026-04-24 | 6.7 Medium |
| Authentication Bypass Using an Alternate Path or Channel vulnerability in Case-Themes Booked booked allows Authentication Abuse.This issue affects Booked: from n/a through <= 3.0.0. | ||||
| CVE-2026-22350 | 2 Add-ons.org, Wordpress | 2 Pdf For Elementor Forms + Drag And Drop Template Builder, Wordpress | 2026-04-24 | 6.5 Medium |
| Missing Authorization vulnerability in add-ons.org PDF for Elementor Forms + Drag And Drop Template Builder pdf-for-elementor-forms allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects PDF for Elementor Forms + Drag And Drop Template Builder: from n/a through <= 6.3.1. | ||||