Total
291487 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-3634 | 2025-04-25 | N/A | 4.3 MEDIUM | ||
| A security vulnerability was discovered in Moodle that allows students to enroll themselves in courses without completing all the necessary safety checks. Specifically, users can sign up for courses prematurely, even if they haven't finished two-step verification processes. | |||||
| CVE-2025-3552 | 2025-04-25 | 7.5 HIGH | 7.3 HIGH | ||
| A vulnerability was found in Lingxing ERP 2. It has been classified as critical. This affects an unknown part of the file /Api/TinyMce/UploadAjax.ashx. The manipulation of the argument File leads to unrestricted upload. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. | |||||
| CVE-2025-3551 | 2025-04-25 | 7.5 HIGH | 7.3 HIGH | ||
| A vulnerability was found in Lingxing ERP 2 and classified as critical. Affected by this issue is the function DoUpload of the file /Api/FileUpload.ashx?method=DoUpload. The manipulation of the argument File leads to unrestricted upload. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. | |||||
| CVE-2024-57375 | 2025-04-25 | N/A | 2.4 LOW | ||
| Andamiro Pump It Up 20th Anniversary (aka Double X or XX/2019) 1.00.0-2.08.3 allows a physically proximate attacker to cause a denial of service (application crash) via certain deselect actions. | |||||
| CVE-2024-49672 | 1 Gief | 1 Google Docs Rsvp | 2025-04-25 | N/A | 7.1 HIGH |
| Cross-Site Request Forgery (CSRF) vulnerability in Gifford Cheung, Brian Watanabe, Chongsun Ahn Google Docs RSVP allows Stored XSS.This issue affects Google Docs RSVP: from n/a through 2.0.1. | |||||
| CVE-2024-6199 | 2025-04-25 | N/A | N/A | ||
| An unauthenticated attacker on the WAN interface, with the ability to intercept Dynamic DNS (DDNS) traffic between DDNS services and the modem, could manipulate specific responses to include code that forces a buffer overflow on the modem. Customers that have not enabled Dynamic DNS on their modem are not vulnerable. | |||||
| CVE-2024-6198 | 2025-04-25 | N/A | N/A | ||
| The device exposes a web interface on ports TCP/3030 and TCP/9882. This web service runs lighttpd, which implements the “SNORE” interface. This interface is affected by a stack buffer overflow vulnerability due to insecure path parsing. An attacker with access to the LAN network interface could use a specially crafted HTTP request to exploit a buffer overflow on the modem. | |||||
| CVE-2025-3912 | 2025-04-25 | N/A | 5.3 MEDIUM | ||
| The WS Form LITE – Drag & Drop Contact Form Builder for WordPress plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the 'get_config' function in all versions up to, and including, 1.10.35. This makes it possible for unauthenticated attackers to read the value of the plugin's settings, including API keys for integrated services. | |||||
| CVE-2025-2986 | 2025-04-25 | N/A | 5.5 MEDIUM | ||
| IBM Maximo Asset Management 7.6.1.3 is vulnerable to stored cross-site scripting. This vulnerability allows a privileged user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. | |||||
| CVE-2025-2470 | 2025-04-25 | N/A | 9.8 CRITICAL | ||
| The Service Finder Bookings plugin for WordPress, used by the Service Finder - Directory and Job Board WordPress Theme, is vulnerable to privilege escalation in all versions up to, and including, 5.1. This is due to a lack of restriction on user role in the 'nsl_registration_store_extra_input' function. This makes it possible for unauthenticated attackers to register an account on the site with an arbitrary role, including Administrator, when registering via a social login. The Nextend Social Login plugin must be installed and configured to exploit the vulnerability. | |||||
| CVE-2024-11917 | 2025-04-25 | N/A | 8.1 HIGH | ||
| The JobSearch WP Job Board plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 2.8.8. This is due to improper configurations in the 'jobsearch_xing_response_data_callback', 'set_access_tokes', and 'google_callback' functions. This makes it possible for unauthenticated attackers to log in as the first connected Xing user, or any connected Xing user if the Xing id is known. It is also possible for unauthenticated attackers to log in as the first connected Google user if the user has logged in, without subsequently logging out, in thirty days. The vulnerability was partially patched in version 2.8.4. | |||||
| CVE-2025-37893 | 2025-04-25 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Fix off-by-one error in build_prologue() Vincent reported that running BPF progs with tailcalls on LoongArch causes kernel hard lockup. Debugging the issues shows that the JITed image missing a jirl instruction at the end of the epilogue. There are two passes in JIT compiling, the first pass set the flags and the second pass generates JIT code based on those flags. With BPF progs mixing bpf2bpf and tailcalls, build_prologue() generates N insns in the first pass and then generates N+1 insns in the second pass. This makes epilogue_offset off by one and we will jump to some unexpected insn and cause lockup. Fix this by inserting a nop insn. | |||||
| CVE-2025-22126 | 2025-04-25 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: md: fix mddev uaf while iterating all_mddevs list While iterating all_mddevs list from md_notify_reboot() and md_exit(), list_for_each_entry_safe is used, and this can race with deletint the next mddev, causing UAF: t1: spin_lock //list_for_each_entry_safe(mddev, n, ...) mddev_get(mddev1) // assume mddev2 is the next entry spin_unlock t2: //remove mddev2 ... mddev_free spin_lock list_del spin_unlock kfree(mddev2) mddev_put(mddev1) spin_lock //continue dereference mddev2->all_mddevs The old helper for_each_mddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex. Hence switch to use list_for_each_entry, in this case mddev_put() can free the mddev1 and it's not safe as well. Refer to md_seq_show(), also factor out a helper mddev_put_locked() to fix this problem. | |||||
| CVE-2025-22077 | 2025-04-25 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: Revert "smb: client: fix TCP timers deadlock after rmmod" This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801. Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is mentioned as CVE-2024-54680, but is actually did not fix anything; The issue can be reproduced on top of it. [0] Also, it reverted the change by commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") and introduced a real issue by reviving the kernel TCP socket. When a reconnect happens for a CIFS connection, the socket state transitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync() in tcp_close() stops all timers for the socket. If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1 forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans. Usually, FIN can be retransmitted by the peer, but if the peer aborts the connection, the issue comes into reality. I warned about this privately by pointing out the exact report [1], but the bogus fix was finally merged. So, we should not stop the timers to finally kill the connection on our side in that case, meaning we must not use a kernel socket for TCP whose sk->sk_net_refcnt is 0. The kernel socket does not have a reference to its netns to make it possible to tear down netns without cleaning up every resource in it. For example, tunnel devices use a UDP socket internally, but we can destroy netns without removing such devices and let it complete during exit. Otherwise, netns would be leaked when the last application died. However, this is problematic for TCP sockets because TCP has timers to close the connection gracefully even after the socket is close()d. The lifetime of the socket and its netns is different from the lifetime of the underlying connection. If the socket user does not maintain the netns lifetime, the timer could be fired after the socket is close()d and its netns is freed up, resulting in use-after-free. Actually, we have seen so many similar issues and converted such sockets to have a reference to netns. That's why I converted the CIFS client socket to have a reference to netns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scope of CIFS and technically wrong in e9f2517a3e18, but **is in-scope and right fix**. Regarding the LOCKDEP issue, we can prevent the module unload by bumping the module refcount when switching the LOCKDDEP key in sock_lock_init_class_and_name(). [2] For a while, let's revert the bogus fix. Note that now we can use sk_net_refcnt_upgrade() for the socket conversion, but I'll do so later separately to make backport easy. | |||||
| CVE-2025-22013 | 2025-04-25 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state There are several problems with the way hyp code lazily saves the host's FPSIMD/SVE state, including: * Host SVE being discarded unexpectedly due to inconsistent configuration of TIF_SVE and CPACR_ELx.ZEN. This has been seen to result in QEMU crashes where SVE is used by memmove(), as reported by Eric Auger: https://issues.redhat.com/browse/RHEL-68997 * Host SVE state is discarded *after* modification by ptrace, which was an unintentional ptrace ABI change introduced with lazy discarding of SVE state. * The host FPMR value can be discarded when running a non-protected VM, where FPMR support is not exposed to a VM, and that VM uses FPSIMD/SVE. In these cases the hyp code does not save the host's FPMR before unbinding the host's FPSIMD/SVE/SME state, leaving a stale value in memory. Avoid these by eagerly saving and "flushing" the host's FPSIMD/SVE/SME state when loading a vCPU such that KVM does not need to save any of the host's FPSIMD/SVE/SME state. For clarity, fpsimd_kvm_prepare() is removed and the necessary call to fpsimd_save_and_flush_cpu_state() is placed in kvm_arch_vcpu_load_fp(). As 'fpsimd_state' and 'fpmr_ptr' should not be used, they are set to NULL; all uses of these will be removed in subsequent patches. Historical problems go back at least as far as v5.17, e.g. erroneous assumptions about TIF_SVE being clear in commit: 8383741ab2e773a9 ("KVM: arm64: Get rid of host SVE tracking/saving") ... and so this eager save+flush probably needs to be backported to ALL stable trees. | |||||
| CVE-2025-21853 | 1 Linux | 1 Linux Kernel | 2025-04-25 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: bpf: avoid holding freeze_mutex during mmap operation We use map->freeze_mutex to prevent races between map_freeze() and memory mapping BPF map contents with writable permissions. The way we naively do this means we'll hold freeze_mutex for entire duration of all the mm and VMA manipulations, which is completely unnecessary. This can potentially also lead to deadlocks, as reported by syzbot in [0]. So, instead, hold freeze_mutex only during writeability checks, bump (proactively) "write active" count for the map, unlock the mutex and proceed with mmap logic. And only if something went wrong during mmap logic, then undo that "write active" counter increment. [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/ | |||||
| CVE-2024-53203 | 1 Linux | 1 Linux Kernel | 2025-04-25 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential array underflow in ucsi_ccg_sync_control() The "command" variable can be controlled by the user via debugfs. The worry is that if con_index is zero then "&uc->ucsi->connector[con_index - 1]" would be an array underflow. | |||||
| CVE-2024-50063 | 1 Linux | 1 Linux Kernel | 2025-04-25 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses. | |||||
| CVE-2024-49569 | 2025-04-25 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: unquiesce admin_q before destroy it Kernel will hang on destroy admin_q while we create ctrl failed, such as following calltrace: PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362 #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b This due to we have quiesced admi_q before cancel requests, but forgot to unquiesce before destroy it, as a result we fail to drain the pending requests, and hang on blk_mq_freeze_queue_wait() forever. Here try to reuse nvme_rdma_teardown_admin_queue() to fix this issue and simplify the code. | |||||
| CVE-2024-46816 | 1 Linux | 1 Linux Kernel | 2025-04-25 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links [Why] Coverity report OVERRUN warning. There are only max_links elements within dc->links. link count could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31. [How] Make sure link count less than max_links. | |||||