Total
12626 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-57936 | 1 Linux | 1 Linux Kernel | 2025-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix max SGEs for the Work Request Gen P7 supports up to 13 SGEs for now. WQE software structure can hold only 6 now. Since the max send sge is reported as 13, the stack can give requests up to 13 SGEs. This is causing traffic failures and system crashes. Use the define for max SGE supported for variable size. This will work for both static and variable WQEs. | ||||
| CVE-2024-57941 | 1 Linux | 1 Linux Kernel | 2025-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled When the caching for a cookie is temporarily disabled (e.g. due to a DIO write on that file), future copying to the cache for that file is disabled until all fds open on that file are closed. However, if netfslib is using the deprecated PG_private_2 method (such as is currently used by ceph), and decides it wants to copy to the cache, netfs_advance_write() will just bail at the first check seeing that the cache stream is unavailable, and indicate that it dealt with all the content. This means that we have no subrequests to provide notifications to drive the state machine or even to pin the request and the request just gets discarded, leaving the folios with PG_private_2 set. Fix this by jumping directly to cancel the request if the cache is not available. That way, we don't remove mark3 from the folio_queue list and netfs_pgpriv2_cancel() will clean up the folios. This was found by running the generic/013 xfstest against ceph with an active cache and the "-o fsc" option passed to ceph. That would usually hang | ||||
| CVE-2024-38095 | 2 Microsoft, Redhat | 3 .net, Visual Studio 2022, Enterprise Linux | 2025-10-14 | 7.5 High |
| .NET and Visual Studio Denial of Service Vulnerability | ||||
| CVE-2024-38105 | 1 Microsoft | 13 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 10 more | 2025-10-14 | 6.5 Medium |
| Windows Layer-2 Bridge Network Driver Denial of Service Vulnerability | ||||
| CVE-2024-38052 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-10-14 | 7.8 High |
| Kernel Streaming WOW Thunk Service Driver Elevation of Privilege Vulnerability | ||||
| CVE-2024-38047 | 1 Microsoft | 11 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 8 more | 2025-10-14 | 7.8 High |
| PowerShell Elevation of Privilege Vulnerability | ||||
| CVE-2024-38033 | 1 Microsoft | 13 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 10 more | 2025-10-14 | 7.3 High |
| PowerShell Elevation of Privilege Vulnerability | ||||
| CVE-2024-38021 | 1 Microsoft | 3 365 Apps, Office, Office Long Term Servicing Channel | 2025-10-14 | 8.8 High |
| Microsoft Outlook Remote Code Execution Vulnerability | ||||
| CVE-2024-38055 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-10-14 | 5.5 Medium |
| Microsoft Windows Codecs Library Information Disclosure Vulnerability | ||||
| CVE-2024-38043 | 1 Microsoft | 11 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 8 more | 2025-10-14 | 7.8 High |
| PowerShell Elevation of Privilege Vulnerability | ||||
| CVE-2022-49074 | 1 Linux | 1 Linux Kernel | 2025-10-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix GICR_CTLR.RWP polling It turns out that our polling of RWP is totally wrong when checking for it in the redistributors, as we test the *distributor* bit index, whereas it is a different bit number in the RDs... Oopsie boo. This is embarassing. Not only because it is wrong, but also because it took *8 years* to notice the blunder... Just fix the damn thing. | ||||
| CVE-2022-49081 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-10-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: highmem: fix checks in __kmap_local_sched_{in,out} When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} check that even slots in the tsk->kmap_ctrl.pteval are unmapped. The slots are initialized with 0 value, but the check is done with pte_none. 0 pte however does not necessarily mean that pte_none will return true. e.g. on xtensa it returns false, resulting in the following runtime warnings: WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108 CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_out+0x51/0x108 __schedule+0x71a/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0 CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_in+0x50/0xe0 finish_task_switch$isra$0+0x1ce/0x2f8 __schedule+0x86e/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f Fix it by replacing !pte_none(pteval) with pte_val(pteval) != 0. | ||||
| CVE-2022-49100 | 1 Linux | 1 Linux Kernel | 2025-10-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: virtio_console: eliminate anonymous module_init & module_exit Eliminate anonymous module_init() and module_exit(), which can lead to confusion or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log. Give each of these init and exit functions unique driver-specific names to eliminate the anonymous names. Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init Example 2: (initcall_debug log) calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1 initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned 0 after 74 usecs | ||||
| CVE-2025-52907 | 1 Totolink | 2 X6000r, X6000r Firmware | 2025-10-14 | 8.8 High |
| Improper Input Validation vulnerability in TOTOLINK X6000R allows Command Injection, File Manipulation.This issue affects X6000R: through V9.4.0cu.1360_B20241207. | ||||
| CVE-2025-62162 | 2025-10-14 | 7.5 High | ||
| cel-rust is a Common Expression Language interpreter written in Rust. Starting in version 0.10.0 and prior to version 0.11.4, parsing certain malformed CEL expressions can cause the parser to panic, terminating the process. When the crate is used to evaluate untrusted expressions (e.g., user-supplied input over an API), an attacker can send crafted input to trigger a denial of service (DoS). Version 0.11.4 fixes the issue. | ||||
| CVE-2025-11346 | 1 Ilias | 1 Ilias | 2025-10-14 | 6.3 Medium |
| A vulnerability has been found in ILIAS up to 8.23/9.13/10.1. This affects the function unserialize of the component Base64 Decoding Handler. Such manipulation of the argument f_settings leads to deserialization. It is possible to launch the attack remotely. Upgrading to version 8.24, 9.14 and 10.2 is able to mitigate this issue. It is advisable to upgrade the affected component. | ||||
| CVE-2025-11345 | 1 Ilias | 1 Ilias | 2025-10-14 | 5.5 Medium |
| A flaw has been found in ILIAS up to 8.23/9.13/10.1. Affected by this issue is the function unserialize of the component Test Import. This manipulation causes deserialization. It is possible to initiate the attack remotely. Upgrading to version 8.24, 9.14 and 10.2 can resolve this issue. Upgrading the affected component is advised. | ||||
| CVE-2025-4260 | 1 Zhangyanbo2007 | 1 Youkefu | 2025-10-10 | 4.3 Medium |
| A vulnerability was found in zhangyanbo2007 youkefu up to 4.2.0 and classified as problematic. Affected by this issue is the function impsave of the file m\web\handler\admin\system\TemplateController.java. The manipulation of the argument dataFile leads to deserialization. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2025-60787 | 1 Motioneye Project | 1 Motioneye | 2025-10-10 | 7.2 High |
| MotionEye v0.43.1b4 and before is vulnerable to OS Command Injection in configuration parameters such as image_file_name. Unsanitized user input is written to Motion configuration files, allowing remote authenticated attackers with admin access to achieve code execution when Motion is restarted. | ||||
| CVE-2022-50232 | 1 Linux | 1 Linux Kernel | 2025-10-10 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: arm64: set UXN on swapper page tables [ This issue was fixed upstream by accident in c3cee924bd85 ("arm64: head: cover entire kernel image in initial ID map") as part of a large refactoring of the arm64 boot flow. This simple fix is therefore preferred for -stable backporting ] On a system that implements FEAT_EPAN, read/write access to the idmap is denied because UXN is not set on the swapper PTEs. As a result, idmap_kpti_install_ng_mappings panics the kernel when accessing __idmap_kpti_flag. Fix it by setting UXN on these PTEs. | ||||