Total
33456 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-21428 | 1 Microsoft | 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more | 2025-10-14 | 8.8 High |
| SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability | ||||
| CVE-2024-21415 | 1 Microsoft | 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more | 2025-10-14 | 8.8 High |
| SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability | ||||
| CVE-2024-21414 | 1 Microsoft | 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more | 2025-10-14 | 8.8 High |
| SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability | ||||
| CVE-2024-21398 | 1 Microsoft | 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more | 2025-10-14 | 8.8 High |
| SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability | ||||
| CVE-2024-21373 | 1 Microsoft | 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more | 2025-10-14 | 8.8 High |
| SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability | ||||
| CVE-2024-21335 | 1 Microsoft | 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more | 2025-10-14 | 8.8 High |
| SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability | ||||
| CVE-2024-21333 | 1 Microsoft | 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more | 2025-10-14 | 8.8 High |
| SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability | ||||
| CVE-2024-21332 | 1 Microsoft | 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more | 2025-10-14 | 8.8 High |
| SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability | ||||
| CVE-2024-38087 | 1 Microsoft | 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more | 2025-10-14 | 8.8 High |
| SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability | ||||
| CVE-2024-38088 | 1 Microsoft | 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more | 2025-10-14 | 8.8 High |
| SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability | ||||
| CVE-2024-35270 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-10-14 | 5.3 Medium |
| Windows iSCSI Service Denial of Service Vulnerability | ||||
| CVE-2024-35264 | 2 Microsoft, Redhat | 3 .net, Visual Studio 2022, Enterprise Linux | 2025-10-14 | 8.1 High |
| .NET and Visual Studio Remote Code Execution Vulnerability | ||||
| CVE-2024-30081 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-10-14 | 7.1 High |
| Windows NTLM Spoofing Vulnerability | ||||
| CVE-2024-28899 | 1 Microsoft | 13 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 10 more | 2025-10-14 | 8.8 High |
| Secure Boot Security Feature Bypass Vulnerability | ||||
| CVE-2024-21417 | 1 Microsoft | 9 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 6 more | 2025-10-14 | 8.8 High |
| Windows Text Services Framework Elevation of Privilege Vulnerability | ||||
| CVE-2024-30061 | 1 Microsoft | 1 Dynamics 365 | 2025-10-14 | 7.3 High |
| Microsoft Dynamics 365 (On-Premises) Information Disclosure 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-49092 | 1 Linux | 1 Linux Kernel | 2025-10-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: ipv4: fix route with nexthop object delete warning FRR folks have hit a kernel warning[1] while deleting routes[2] which is caused by trying to delete a route pointing to a nexthop id without specifying nhid but matching on an interface. That is, a route is found but we hit a warning while matching it. The warning is from fib_info_nh() in include/net/nexthop.h because we run it on a fib_info with nexthop object. The call chain is: inet_rtm_delroute -> fib_table_delete -> fib_nh_match (called with a nexthop fib_info and also with fc_oif set thus calling fib_info_nh on the fib_info and triggering the warning). The fix is to not do any matching in that branch if the fi has a nexthop object because those are managed separately. I.e. we should match when deleting without nh spec and should fail when deleting a nexthop route with old-style nh spec because nexthop objects are managed separately, e.g.: $ ip r show 1.2.3.4/32 1.2.3.4 nhid 12 via 192.168.11.2 dev dummy0 $ ip r del 1.2.3.4/32 $ ip r del 1.2.3.4/32 nhid 12 <both should work> $ ip r del 1.2.3.4/32 dev dummy0 <should fail with ESRCH> [1] [ 523.462226] ------------[ cut here ]------------ [ 523.462230] WARNING: CPU: 14 PID: 22893 at include/net/nexthop.h:468 fib_nh_match+0x210/0x460 [ 523.462236] Modules linked in: dummy rpcsec_gss_krb5 xt_socket nf_socket_ipv4 nf_socket_ipv6 ip6table_raw iptable_raw bpf_preload xt_statistic ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs xt_mark nf_tables xt_nat veth nf_conntrack_netlink nfnetlink xt_addrtype br_netfilter overlay dm_crypt nfsv3 nfs fscache netfs vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack 8021q garp mrp ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bridge stp llc rfcomm snd_seq_dummy snd_hrtimer rpcrdma rdma_cm iw_cm ib_cm ib_core ip6table_filter xt_comment ip6_tables vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) qrtr bnep binfmt_misc xfs vfat fat squashfs loop nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(POE) nvidia(POE) intel_rapl_msr intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi btusb btrtl iwlmvm uvcvideo btbcm snd_hda_intel edac_mce_amd [ 523.462274] videobuf2_vmalloc videobuf2_memops btintel snd_intel_dspcfg videobuf2_v4l2 snd_intel_sdw_acpi bluetooth snd_usb_audio snd_hda_codec mac80211 snd_usbmidi_lib joydev snd_hda_core videobuf2_common kvm_amd snd_rawmidi snd_hwdep snd_seq videodev ccp snd_seq_device libarc4 ecdh_generic mc snd_pcm kvm iwlwifi snd_timer drm_kms_helper snd cfg80211 cec soundcore irqbypass rapl wmi_bmof i2c_piix4 rfkill k10temp pcspkr acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc drm zram ip_tables crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel nvme sp5100_tco r8169 nvme_core wmi ipmi_devintf ipmi_msghandler fuse [ 523.462300] CPU: 14 PID: 22893 Comm: ip Tainted: P OE 5.16.18-200.fc35.x86_64 #1 [ 523.462302] Hardware name: Micro-Star International Co., Ltd. MS-7C37/MPG X570 GAMING EDGE WIFI (MS-7C37), BIOS 1.C0 10/29/2020 [ 523.462303] RIP: 0010:fib_nh_match+0x210/0x460 [ 523.462304] Code: 7c 24 20 48 8b b5 90 00 00 00 e8 bb ee f4 ff 48 8b 7c 24 20 41 89 c4 e8 ee eb f4 ff 45 85 e4 0f 85 2e fe ff ff e9 4c ff ff ff <0f> 0b e9 17 ff ff ff 3c 0a 0f 85 61 fe ff ff 48 8b b5 98 00 00 00 [ 523.462306] RSP: 0018:ffffaa53d4d87928 EFLAGS: 00010286 [ 523.462307] RAX: 0000000000000000 RBX: ffffaa53d4d87a90 RCX: ffffaa53d4d87bb0 [ 523.462308] RDX: ffff9e3d2ee6be80 RSI: ffffaa53d4d87a90 RDI: ffffffff920ed380 [ 523.462309] RBP: ffff9e3d2ee6be80 R08: 0000000000000064 R09: 0000000000000000 [ 523.462310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000031 [ 523.462310] R13: 0000000000000020 R14: 0000000000000000 R15: ffff9e3d331054e0 [ 523.462311] FS: 00007f2455 ---truncated--- | ||||
| CVE-2022-49098 | 1 Linux | 1 Linux Kernel | 2025-10-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Fix potential crash on module unload The vmbus driver relies on the panic notifier infrastructure to perform some operations when a panic event is detected. Since vmbus can be built as module, it is required that the driver handles both registering and unregistering such panic notifier callback. After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback") though, the panic notifier registration is done unconditionally in the module initialization routine whereas the unregistering procedure is conditionally guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability is set. This patch fixes that by unconditionally unregistering the panic notifier in the module's exit routine as well. | ||||