Total
34062 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-38151 | 1 Microsoft | 2 Host Integration Server, Ole Db Provider | 2025-10-08 | 8.8 High |
| Microsoft Host Integration Server 2020 Remote Code Execution Vulnerability | ||||
| CVE-2023-36423 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-10-08 | 8.8 High |
| Microsoft Remote Registry Service Remote Code Execution Vulnerability | ||||
| CVE-2023-36424 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-10-08 | 7.8 High |
| Windows Common Log File System Driver Elevation of Privilege Vulnerability | ||||
| CVE-2023-36425 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-10-08 | 8 High |
| Windows Distributed File System (DFS) Remote Code Execution Vulnerability | ||||
| CVE-2023-36427 | 1 Microsoft | 9 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 6 more | 2025-10-08 | 7 High |
| Windows Hyper-V Elevation of Privilege Vulnerability | ||||
| CVE-2023-36428 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-10-08 | 5.5 Medium |
| Microsoft Local Security Authority Subsystem Service Information Disclosure Vulnerability | ||||
| CVE-2023-36439 | 1 Microsoft | 1 Exchange Server | 2025-10-08 | 8 High |
| Microsoft Exchange Server Remote Code Execution Vulnerability | ||||
| CVE-2023-38177 | 1 Microsoft | 2 Sharepoint Enterprise Server, Sharepoint Server | 2025-10-08 | 6.1 Medium |
| Microsoft SharePoint Server Remote Code Execution Vulnerability | ||||
| CVE-2023-36413 | 1 Microsoft | 3 365 Apps, Office, Office Long Term Servicing Channel | 2025-10-08 | 6.5 Medium |
| Microsoft Office Security Feature Bypass Vulnerability | ||||
| CVE-2025-11026 | 2 Givanz, Vvveb | 2 Vvveb, Vvveb | 2025-10-08 | 3.5 Low |
| A vulnerability was determined in givanz Vvveb up to 1.0.7.2. Affected by this vulnerability is an unknown functionality of the component Configuration File Handler. This manipulation causes information disclosure. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. Once again the project maintainer reacted very professional: "I accept the existence of these vulnerabilities. (...) I fixed the code to remove these vulnerabilities and will push the code to github and make a new release." | ||||
| CVE-2025-52905 | 1 Totolink | 2 X6000r, X6000r Firmware | 2025-10-08 | 7.5 High |
| Improper Input Validation vulnerability in TOTOLINK X6000R allows Flooding.This issue affects X6000R: through V9.4.0cu.1360_B20241207. | ||||
| CVE-2022-48945 | 1 Linux | 1 Linux Kernel | 2025-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix compose size exceed boundary syzkaller found a bug: BUG: unable to handle page fault for address: ffffc9000a3b1000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0 Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:memcpy_erms+0x6/0x10 [...] Call Trace: <TASK> ? tpg_fill_plane_buffer+0x856/0x15b0 vivid_fillbuff+0x8ac/0x1110 vivid_thread_vid_cap_tick+0x361/0xc90 vivid_thread_vid_cap+0x21a/0x3a0 kthread+0x143/0x180 ret_from_fork+0x1f/0x30 </TASK> This is because we forget to check boundary after adjust compose->height int V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem for this case. | ||||
| CVE-2024-46718 | 1 Linux | 1 Linux Kernel | 2025-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe: Don't overmap identity VRAM mapping Overmapping the identity VRAM mapping is triggering hardware bugs on certain platforms. Use 2M pages for the last unaligned (to 1G) VRAM chunk. v2: - Always use 2M pages for last chunk (Fei Yang) - break loop when 2M pages are used - Add assert for usable_size being 2M aligned v3: - Fix checkpatch | ||||
| CVE-2024-46748 | 1 Linux | 1 Linux Kernel | 2025-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: cachefiles: Set the max subreq size for cache writes to MAX_RW_COUNT Set the maximum size of a subrequest that writes to cachefiles to be MAX_RW_COUNT so that we don't overrun the maximum write we can make to the backing filesystem. | ||||
| CVE-2024-46754 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Remove tst_run from lwt_seg6local_prog_ops. The syzbot reported that the lwt_seg6 related BPF ops can be invoked via bpf_test_run() without without entering input_action_end_bpf() first. Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a ("ipv6: sr: Add seg6local action End.BPF"). The reason is that the per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self test case but each BPF function expects it. Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL. | ||||
| CVE-2024-50216 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory. | ||||
| CVE-2024-50289 | 1 Linux | 1 Linux Kernel | 2025-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it. | ||||
| CVE-2024-53152 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert() Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF deinit notify function pci_epc_deinit_notify() are called during the execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted PERST#. But quickly after this step, refclk will also be disabled by the host. All of the tegra194 endpoint SoCs supported as of now depend on the refclk from the host for keeping the controller operational. Due to this limitation, any access to the hardware registers in the absence of refclk will result in a whole endpoint crash. Unfortunately, most of the controller cleanups require accessing the hardware registers (like eDMA cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup functions can cause the crash in the endpoint SoC once host asserts PERST#. One way to address this issue is by generating the refclk in the endpoint itself and not depending on the host. But that is not always possible as some of the endpoint designs do require the endpoint to consume refclk from the host. Thus, fix this crash by moving the controller cleanups to the start of the pex_ep_event_pex_rst_deassert() function. This function is called whenever the host has deasserted PERST# and it is guaranteed that the refclk would be active at this point. So at the start of this function (after enabling resources) the controller cleanup can be performed. Once finished, rest of the code execution for PERST# deassert can continue as usual. | ||||
| CVE-2024-53153 | 1 Linux | 1 Linux Kernel | 2025-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert() Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF deinit notify function pci_epc_deinit_notify() are called during the execution of qcom_pcie_perst_assert() i.e., when the host has asserted PERST#. But quickly after this step, refclk will also be disabled by the host. All of the Qcom endpoint SoCs supported as of now depend on the refclk from the host for keeping the controller operational. Due to this limitation, any access to the hardware registers in the absence of refclk will result in a whole endpoint crash. Unfortunately, most of the controller cleanups require accessing the hardware registers (like eDMA cleanup performed in dw_pcie_ep_cleanup(), powering down MHI EPF etc...). So these cleanup functions are currently causing the crash in the endpoint SoC once host asserts PERST#. One way to address this issue is by generating the refclk in the endpoint itself and not depending on the host. But that is not always possible as some of the endpoint designs do require the endpoint to consume refclk from the host (as I was told by the Qcom engineers). Thus, fix this crash by moving the controller cleanups to the start of the qcom_pcie_perst_deassert() function. qcom_pcie_perst_deassert() is called whenever the host has deasserted PERST# and it is guaranteed that the refclk would be active at this point. So at the start of this function (after enabling resources), the controller cleanup can be performed. Once finished, rest of the code execution for PERST# deassert can continue as usual. | ||||
| CVE-2024-53176 | 1 Linux | 1 Linux Kernel | 2025-10-08 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: smb: During unmount, ensure all cached dir instances drop their dentry The unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can race with various cached directory operations, which ultimately results in dentries not being dropped and these kernel BUGs: BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) ------------[ cut here ]------------ kernel BUG at fs/super.c:661! This happens when a cfid is in the process of being cleaned up when, and has been removed from the cfids->entries list, including: - Receiving a lease break from the server - Server reconnection triggers invalidate_all_cached_dirs(), which removes all the cfids from the list - The laundromat thread decides to expire an old cfid. To solve these problems, dropping the dentry is done in queued work done in a newly-added cfid_put_wq workqueue, and close_all_cached_dirs() flushes that workqueue after it drops all the dentries of which it's aware. This is a global workqueue (rather than scoped to a mount), but the queued work is minimal. The final cleanup work for cleaning up a cfid is performed via work queued in the serverclose_wq workqueue; this is done separate from dropping the dentries so that close_all_cached_dirs() doesn't block on any server operations. Both of these queued works expect to invoked with a cfid reference and a tcon reference to avoid those objects from being freed while the work is ongoing. While we're here, add proper locking to close_all_cached_dirs(), and locking around the freeing of cfid->dentry. | ||||