Export limit exceeded: 344961 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (344961 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-23138 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Add recursion protection in kernel stack trace recording A bug was reported about an infinite recursion caused by tracing the rcu events with the kernel stack trace trigger enabled. The stack trace code called back into RCU which then called the stack trace again. Expand the ftrace recursion protection to add a set of bits to protect events from recursion. Each bit represents the context that the event is in (normal, softirq, interrupt and NMI). Have the stack trace code use the interrupt context to protect against recursion. Note, the bug showed an issue in both the RCU code as well as the tracing stacktrace code. This only handles the tracing stack trace side of the bug. The RCU fix will be handled separately. | ||||
| CVE-2026-23148 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: nvmet: fix race in nvmet_bio_done() leading to NULL pointer dereference There is a race condition in nvmet_bio_done() that can cause a NULL pointer dereference in blk_cgroup_bio_start(): 1. nvmet_bio_done() is called when a bio completes 2. nvmet_req_complete() is called, which invokes req->ops->queue_response(req) 3. The queue_response callback can re-queue and re-submit the same request 4. The re-submission reuses the same inline_bio from nvmet_req 5. Meanwhile, nvmet_req_bio_put() (called after nvmet_req_complete) invokes bio_uninit() for inline_bio, which sets bio->bi_blkg to NULL 6. The re-submitted bio enters submit_bio_noacct_nocheck() 7. blk_cgroup_bio_start() dereferences bio->bi_blkg, causing a crash: BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode RIP: 0010:blk_cgroup_bio_start+0x10/0xd0 Call Trace: submit_bio_noacct_nocheck+0x44/0x250 nvmet_bdev_execute_rw+0x254/0x370 [nvmet] process_one_work+0x193/0x3c0 worker_thread+0x281/0x3a0 Fix this by reordering nvmet_bio_done() to call nvmet_req_bio_put() BEFORE nvmet_req_complete(). This ensures the bio is cleaned up before the request can be re-submitted, preventing the race condition. | ||||
| CVE-2026-23157 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: do not strictly require dirty metadata threshold for metadata writepages [BUG] There is an internal report that over 1000 processes are waiting at the io_schedule_timeout() of balance_dirty_pages(), causing a system hang and trigger a kernel coredump. The kernel is v6.4 kernel based, but the root problem still applies to any upstream kernel before v6.18. [CAUSE] From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup. So that means the only way to reduce the dirty pages of that cgroup is to writeback the dirty pages of btrfs btree inode, and only after that those processes can exit balance_dirty_pages(). Now back to the btrfs part, btree_writepages() is responsible for writing back dirty btree inode pages. The problem here is, there is a btrfs internal threshold that if the btree inode's dirty bytes are below the 32M threshold, it will not do any writeback. This behavior is to batch as much metadata as possible so we won't write back those tree blocks and then later re-COW them again for another modification. This internal 32MiB is higher than the existing dirty page size (28MiB), meaning no writeback will happen, causing a deadlock between btrfs and cgroup: - Btrfs doesn't want to write back btree inode until more dirty pages - Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced. Thanks Jan Kara a lot for the analysis of the root cause. [ENHANCEMENT] Since kernel commit b55102826d7d ("btrfs: set AS_KERNEL_FILE on the btree_inode"), btrfs btree inode pages will only be charged to the root cgroup which should have a much larger limit than btrfs' 32MiB threshold. So it should not affect newer kernels. But for all current LTS kernels, they are all affected by this problem, and backporting the whole AS_KERNEL_FILE may not be a good idea. Even for newer kernels I still think it's a good idea to get rid of the internal threshold at btree_writepages(), since for most cases cgroup/MM has a better view of full system memory usage than btrfs' fixed threshold. For internal callers using btrfs_btree_balance_dirty() since that function is already doing internal threshold check, we don't need to bother them. But for external callers of btree_writepages(), just respect their requests and write back whatever they want, ignoring the internal btrfs threshold to avoid such deadlock on btree inode dirty page balancing. | ||||
| CVE-2026-23169 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race in mptcp_pm_nl_flush_addrs_doit() syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id() and/or mptcp_pm_nl_is_backup() Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit() which is not RCU ready. list_splice_init_rcu() can not be called here while holding pernet->lock spinlock. Many thanks to Eulgyu Kim for providing a repro and testing our patches. | ||||
| CVE-2026-23198 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: KVM: Don't clobber irqfd routing type when deassigning irqfd When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86 and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to handle a concurrent routing update, verify that the irqfd is still active before consuming the routing information. As evidenced by the x86 and arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below), clobbering the entry type without notifying arch code is surprising and error prone. As a bonus, checking that the irqfd is active provides a convenient location for documenting _why_ KVM must not consume the routing entry for an irqfd that is in the process of being deassigned: once the irqfd is deleted from the list (which happens *before* the eventfd is detached), it will no longer receive updates via kvm_irq_routing_update(), and so KVM could deliver an event using stale routing information (relative to KVM_SET_GSI_ROUTING returning to userspace). As an even better bonus, explicitly checking for the irqfd being active fixes a similar bug to the one the clobbering is trying to prevent: if an irqfd is deactivated, and then its routing is changed, kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing() (because the irqfd isn't in the list). And so if the irqfd is in bypass mode, IRQs will continue to be posted using the old routing information. As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type results in KVM incorrectly keeping the IRQ in bypass mode, which is especially problematic on AMD as KVM tracks IRQs that are being posted to a vCPU in a list whose lifetime is tied to the irqfd. Without the help of KASAN to detect use-after-free, the most common sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to the memory for irqfd structure being re-allocated and zeroed, resulting in irqfd->irq_bypass_data being NULL when read by avic_update_iommu_vcpu_affinity(): BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Call Trace: <TASK> avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b </TASK> ---[ end trace 0000000000000000 ]--- If AVIC is inhibited when the irfd is deassigned, the bug will manifest as list corruption, e.g. on the next irqfd assignment. list_add corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:__list_add_valid_or_report+0x97/0xc0 Call Trace: <TASK> avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] kvm_pi_update_irte+0xbf/0x190 [kvm] kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] irq_bypass_register_consumer+0xcd/0x170 [irqbypa ---truncated--- | ||||
| CVE-2026-26731 | 1 Totolink | 3 A3002ru, A3002ru-v2, A3002ru Firmware | 2026-04-16 | 8 High |
| TOTOLINK A3002RU V2.1.1-B20211108.1455 was discovered to contain a stack-based buffer overflow via the routernamer`parameter in the formDnsv6 function. | ||||
| CVE-2026-26732 | 1 Totolink | 3 A3002ru, A3002ru-v2, A3002ru Firmware | 2026-04-16 | 8.8 High |
| TOTOLINK A3002RU V2.1.1-B20211108.1455 was discovered to contain a stack-based buffer overflow via the vpnUser or vpnPassword` parameters in the formFilter function. | ||||
| CVE-2026-24733 | 2 Apache, Apache Tomcat | 2 Tomcat, Apache Tomcat | 2026-04-16 | 6.5 Medium |
| Improper Input Validation vulnerability in Apache Tomcat. Tomcat did not limit HTTP/0.9 requests to the GET method. If a security constraint was configured to allow HEAD requests to a URI but deny GET requests, the user could bypass that constraint on GET requests by sending a (specification invalid) HEAD request using HTTP/0.9. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0.M1 through 9.0.112. Older, EOL versions are also affected. Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fixes the issue. | ||||
| CVE-2026-24734 | 2 Apache, Apache Tomcat | 3 Tomcat, Tomcat Native, Apache Tomcat | 2026-04-16 | 7.4 High |
| Improper Input Validation vulnerability in Apache Tomcat Native, Apache Tomcat. When using an OCSP responder, Tomcat Native (and Tomcat's FFM port of the Tomcat Native code) did not complete verification or freshness checks on the OCSP response which could allow certificate revocation to be bypassed. This issue affects Apache Tomcat Native: from 1.3.0 through 1.3.4, from 2.0.0 through 2.0.11; Apache Tomcat: from 11.0.0-M1 through 11.0.17, from 10.1.0-M7 through 10.1.51, from 9.0.83 through 9.0.114. The following versions were EOL at the time the CVE was created but are known to be affected: from 1.1.23 through 1.1.34, from 1.2.0 through 1.2.39. Older EOL versions are not affected. Apache Tomcat Native users are recommended to upgrade to versions 1.3.5 or later or 2.0.12 or later, which fix the issue. Apache Tomcat users are recommended to upgrade to versions 11.0.18 or later, 10.1.52 or later or 9.0.115 or later which fix the issue. | ||||
| CVE-2026-1405 | 2 Franchidesign, Wordpress | 2 Slider Future, Wordpress | 2026-04-16 | 9.8 Critical |
| The Slider Future plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the 'slider_future_handle_image_upload' function in all versions up to, and including, 1.0.5. This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible. | ||||
| CVE-2026-1047 | 2 Goback2, Wordpress | 2 Salavat Counter Plugin, Wordpress | 2026-04-16 | 4.4 Medium |
| The salavat counter Plugin plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'image_url' parameter in all versions up to, and including, 0.9.5 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | ||||
| CVE-2026-22333 | 2 Wordpress, Yithemes | 2 Wordpress, Yith Woocommerce Compare | 2026-04-16 | 7.2 High |
| Deserialization of Untrusted Data vulnerability in YITHEMES YITH WooCommerce Compare yith-woocommerce-compare allows Object Injection.This issue affects YITH WooCommerce Compare: from n/a through <= 3.6.0. | ||||
| CVE-2026-22422 | 2 Wordpress, Wpeverest | 2 Wordpress, Everest Forms | 2026-04-16 | 5.3 Medium |
| Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in wpeverest Everest Forms everest-forms allows Code Injection.This issue affects Everest Forms: from n/a through <= 3.4.1. | ||||
| CVE-2026-23541 | 2 Getwpfunnels, Wordpress | 2 Mail Mint, Wordpress | 2026-04-16 | N/A |
| Missing Authorization vulnerability in WPFunnels Mail Mint mail-mint allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Mail Mint: from n/a through <= 1.19.4. | ||||
| CVE-2026-23545 | 2 Arubadev, Wordpress | 2 Aruba Hispeed Cache, Wordpress | 2026-04-16 | 6.5 Medium |
| Missing Authorization vulnerability in Aruba.it Dev Aruba HiSpeed Cache aruba-hispeed-cache allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Aruba HiSpeed Cache: from n/a through <= 3.0.4. | ||||
| CVE-2026-23547 | 2 Cmsmasters, Wordpress | 2 Cmsmasters Content Composer, Wordpress | 2026-04-16 | 7.1 High |
| Missing Authorization vulnerability in cmsmasters CMSMasters Content Composer cmsmasters-content-composer allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects CMSMasters Content Composer: from n/a through <= 2.5.8. | ||||
| CVE-2026-23549 | 2 Magepeopleteam, Wordpress | 2 Wpevently, Wordpress | 2026-04-16 | 9.8 Critical |
| Deserialization of Untrusted Data vulnerability in magepeopleteam WpEvently mage-eventpress allows Object Injection.This issue affects WpEvently: from n/a through <= 5.1.1. | ||||
| CVE-2026-23804 | 2 Bbr Plugins, Wordpress | 2 Better Business Reviews, Wordpress | 2026-04-16 | 5.4 Medium |
| Missing Authorization vulnerability in BBR Plugins Better Business Reviews better-business-reviews allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Better Business Reviews: from n/a through <= 0.1.1. | ||||
| CVE-2026-23805 | 2 Wordpress, Yoren Chang | 2 Wordpress, Media Search Enhanced | 2026-04-16 | 7.6 High |
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Yoren Chang Media Search Enhanced media-search-enhanced allows SQL Injection.This issue affects Media Search Enhanced: from n/a through <= 0.9.1. | ||||
| CVE-2026-25006 | 2 8theme, Wordpress | 2 Xstore, Wordpress | 2026-04-16 | 5.3 Medium |
| Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in 8theme XStore xstore allows Code Injection.This issue affects XStore: from n/a through <= 9.6.4. | ||||