|
|
Search Results
There are 234 CVE Records that match your search.
| Name | Description |
|---|---|
| CVE-2025-48822 | Out-of-bounds read in Windows Hyper-V allows an unauthorized attacker to execute code locally. |
| CVE-2025-48002 | Integer overflow or wraparound in Windows Hyper-V allows an authorized attacker to disclose information over an adjacent network. |
| CVE-2025-47999 | Missing synchronization in Windows Hyper-V allows an authorized attacker to deny service over an adjacent network. |
| CVE-2025-38104 | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOV RLCG Register Access is a way for virtual functions to safely access GPU registers in a virtualized environment., including TLB flushes and register reads. When multiple threads or VFs try to access the same registers simultaneously, it can lead to race conditions. By using the RLCG interface, the driver can serialize access to the registers. This means that only one thread can access the registers at a time, preventing conflicts and ensuring that operations are performed correctly. Additionally, when a low-priority task holds a mutex that a high-priority task needs, ie., If a thread holding a spinlock tries to acquire a mutex, it can lead to priority inversion. register access in amdgpu_virt_rlcg_reg_rw especially in a fast code path is critical. The call stack shows that the function amdgpu_virt_rlcg_reg_rw is being called, which attempts to acquire the mutex. This function is invoked from amdgpu_sriov_wreg, which in turn is called from gmc_v11_0_flush_gpu_tlb. The [ BUG: Invalid wait context ] indicates that a thread is trying to acquire a mutex while it is in a context that does not allow it to sleep (like holding a spinlock). Fixes the below: [ 253.013423] ============================= [ 253.013434] [ BUG: Invalid wait context ] [ 253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE [ 253.013464] ----------------------------- [ 253.013475] kworker/0:1/10 is trying to lock: [ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.013815] other info that might help us debug this: [ 253.013827] context-{4:4} [ 253.013835] 3 locks held by kworker/0:1/10: [ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680 [ 253.013877] #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680 [ 253.013905] #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu] [ 253.014154] stack backtrace: [ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14 [ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024 [ 253.014224] Workqueue: events work_for_cpu_fn [ 253.014241] Call Trace: [ 253.014250] <TASK> [ 253.014260] dump_stack_lvl+0x9b/0xf0 [ 253.014275] dump_stack+0x10/0x20 [ 253.014287] __lock_acquire+0xa47/0x2810 [ 253.014303] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014321] lock_acquire+0xd1/0x300 [ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014562] ? __lock_acquire+0xa6b/0x2810 [ 253.014578] __mutex_lock+0x85/0xe20 [ 253.014591] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014782] ? sched_clock_noinstr+0x9/0x10 [ 253.014795] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014808] ? local_clock_noinstr+0xe/0xc0 [ 253.014822] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015012] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.015029] mutex_lock_nested+0x1b/0x30 [ 253.015044] ? mutex_lock_nested+0x1b/0x30 [ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015249] amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu] [ 253.015435] gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu] [ 253.015667] gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu] [ 253.015901] ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu] [ 253.016159] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.016173] ? smu_hw_init+0x18d/0x300 [amdgpu] [ 253.016403] amdgpu_device_init+0x29ad/0x36a0 [amdgpu] [ 253.016614] amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu] [ 253.0170 ---truncated--- |
| CVE-2025-29955 | Improper input validation in Windows Hyper-V allows an unauthorized attacker to deny service locally. |
| CVE-2025-27491 | Use after free in Windows Hyper-V allows an authorized attacker to execute code over a network. |
| CVE-2025-24050 | Heap-based buffer overflow in Role: Windows Hyper-V allows an authorized attacker to elevate privileges locally. |
| CVE-2025-24048 | Heap-based buffer overflow in Role: Windows Hyper-V allows an authorized attacker to elevate privileges locally. |
| CVE-2025-22045 | In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs On the following path, flush_tlb_range() can be used for zapping normal PMD entries (PMD entries that point to page tables) together with the PTE entries in the pointed-to page table: collapse_pte_mapped_thp pmdp_collapse_flush flush_tlb_range The arm64 version of flush_tlb_range() has a comment describing that it can be used for page table removal, and does not use any last-level invalidation optimizations. Fix the X86 version by making it behave the same way. Currently, X86 only uses this information for the following two purposes, which I think means the issue doesn't have much impact: - In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be IPI'd to avoid issues with speculative page table walks. - In Hyper-V TLB paravirtualization, again for lazy TLB stuff. The patch "x86/mm: only invalidate final translations with INVLPGB" which is currently under review (see <https://lore.kernel.org/all/20241230175550.4046587-13-riel@surriel.com/>) would probably be making the impact of this a lot worse. |
| CVE-2025-21978 | In the Linux kernel, the following vulnerability has been resolved: drm/hyperv: Fix address space leak when Hyper-V DRM device is removed When a Hyper-V DRM device is probed, the driver allocates MMIO space for the vram, and maps it cacheable. If the device removed, or in the error path for device probing, the MMIO space is released but no unmap is done. Consequently the kernel address space for the mapping is leaked. Fix this by adding iounmap() calls in the device removal path, and in the error path during device probing. |
| CVE-2025-21977 | In the Linux kernel, the following vulnerability has been resolved: fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs Gen 2 Hyper-V VMs boot via EFI and have a standard EFI framebuffer device. When the kdump kernel runs in such a VM, loading the efifb driver may hang because of accessing the framebuffer at the wrong memory address. The scenario occurs when the hyperv_fb driver in the original kernel moves the framebuffer to a different MMIO address because of conflicts with an already-running efifb or simplefb driver. The hyperv_fb driver then informs Hyper-V of the change, which is allowed by the Hyper-V FB VMBus device protocol. However, when the kexec command loads the kdump kernel into crash memory via the kexec_file_load() system call, the system call doesn't know the framebuffer has moved, and it sets up the kdump screen_info using the original framebuffer address. The transition to the kdump kernel does not go through the Hyper-V host, so Hyper-V does not reset the framebuffer address like it would do on a reboot. When efifb tries to run, it accesses a non-existent framebuffer address, which traps to the Hyper-V host. After many such accesses, the Hyper-V host thinks the guest is being malicious, and throttles the guest to the point that it runs very slowly or appears to have hung. When the kdump kernel is loaded into crash memory via the kexec_load() system call, the problem does not occur. In this case, the kexec command builds the screen_info table itself in user space from data returned by the FBIOGET_FSCREENINFO ioctl against /dev/fb0, which gives it the new framebuffer location. This problem was originally reported in 2020 [1], resulting in commit 3cb73bc3fa2a ("hyperv_fb: Update screen_info after removing old framebuffer"). This commit solved the problem by setting orig_video_isVGA to 0, so the kdump kernel was unaware of the EFI framebuffer. The efifb driver did not try to load, and no hang occurred. But in 2024, commit c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen_info") effectively reverted 3cb73bc3fa2a. Commit c25a19afb81c has no reference to 3cb73bc3fa2a, so perhaps it was done without knowing the implications that were reported with 3cb73bc3fa2a. In any case, as of commit c25a19afb81c, the original problem came back again. Interestingly, the hyperv_drm driver does not have this problem because it never moves the framebuffer. The difference is that the hyperv_drm driver removes any conflicting framebuffers *before* allocating an MMIO address, while the hyperv_fb drivers removes conflicting framebuffers *after* allocating an MMIO address. With the "after" ordering, hyperv_fb may encounter a conflict and move the framebuffer to a different MMIO address. But the conflict is essentially bogus because it is removed a few lines of code later. Rather than fix the problem with the approach from 2020 in commit 3cb73bc3fa2a, instead slightly reorder the steps in hyperv_fb so conflicting framebuffers are removed before allocating an MMIO address. Then the default framebuffer MMIO address should always be available, and there's never any confusion about which framebuffer address the kdump kernel should use -- it's always the original address provided by the Hyper-V host. This approach is already used by the hyperv_drm driver, and is consistent with the usage guidelines at the head of the module with the function aperture_remove_conflicting_devices(). This approach also solves a related minor problem when kexec_load() is used to load the kdump kernel. With current code, unbinding and rebinding the hyperv_fb driver could result in the framebuffer moving back to the default framebuffer address, because on the rebind there are no conflicts. If such a move is done after the kdump kernel is loaded with the new framebuffer address, at kdump time it could again have the wrong address. This problem and fix are described in terms of the kdump kernel, but it can also occur ---truncated--- |
| CVE-2025-21976 | In the Linux kernel, the following vulnerability has been resolved: fbdev: hyperv_fb: Allow graceful removal of framebuffer When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to release the framebuffer forcefully. If this framebuffer is in use it produce the following WARN and hence this framebuffer is never released. [ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40 < snip > [ 44.111289] Call Trace: [ 44.111290] <TASK> [ 44.111291] ? show_regs+0x6c/0x80 [ 44.111295] ? __warn+0x8d/0x150 [ 44.111298] ? framebuffer_release+0x2c/0x40 [ 44.111300] ? report_bug+0x182/0x1b0 [ 44.111303] ? handle_bug+0x6e/0xb0 [ 44.111306] ? exc_invalid_op+0x18/0x80 [ 44.111308] ? asm_exc_invalid_op+0x1b/0x20 [ 44.111311] ? framebuffer_release+0x2c/0x40 [ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb] [ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus] [ 44.111323] device_remove+0x40/0x80 [ 44.111325] device_release_driver_internal+0x20b/0x270 [ 44.111327] ? bus_find_device+0xb3/0xf0 Fix this by moving the release of framebuffer and assosiated memory to fb_ops.fb_destroy function, so that framebuffer framework handles it gracefully. While we fix this, also replace manual registrations/unregistration of framebuffer with devm_register_framebuffer. |
| CVE-2025-21953 | In the Linux kernel, the following vulnerability has been resolved: net: mana: cleanup mana struct after debugfs_remove() When on a MANA VM hibernation is triggered, as part of hibernate_snapshot(), mana_gd_suspend() and mana_gd_resume() are called. If during this mana_gd_resume(), a failure occurs with HWC creation, mana_port_debugfs pointer does not get reinitialized and ends up pointing to older, cleaned-up dentry. Further in the hibernation path, as part of power_down(), mana_gd_shutdown() is triggered. This call, unaware of the failures in resume, tries to cleanup the already cleaned up mana_port_debugfs value and hits the following bug: [ 191.359296] mana 7870:00:00.0: Shutdown was called [ 191.359918] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 191.360584] #PF: supervisor write access in kernel mode [ 191.361125] #PF: error_code(0x0002) - not-present page [ 191.361727] PGD 1080ea067 P4D 0 [ 191.362172] Oops: Oops: 0002 [#1] SMP NOPTI [ 191.362606] CPU: 11 UID: 0 PID: 1674 Comm: bash Not tainted 6.14.0-rc5+ #2 [ 191.363292] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024 [ 191.364124] RIP: 0010:down_write+0x19/0x50 [ 191.364537] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 de cd ff ff 31 c0 ba 01 00 00 00 <f0> 48 0f b1 13 75 16 65 48 8b 05 88 24 4c 6a 48 89 43 08 48 8b 5d [ 191.365867] RSP: 0000:ff45fbe0c1c037b8 EFLAGS: 00010246 [ 191.366350] RAX: 0000000000000000 RBX: 0000000000000098 RCX: ffffff8100000000 [ 191.366951] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098 [ 191.367600] RBP: ff45fbe0c1c037c0 R08: 0000000000000000 R09: 0000000000000001 [ 191.368225] R10: ff45fbe0d2b01000 R11: 0000000000000008 R12: 0000000000000000 [ 191.368874] R13: 000000000000000b R14: ff43dc27509d67c0 R15: 0000000000000020 [ 191.369549] FS: 00007dbc5001e740(0000) GS:ff43dc663f380000(0000) knlGS:0000000000000000 [ 191.370213] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 191.370830] CR2: 0000000000000098 CR3: 0000000168e8e002 CR4: 0000000000b73ef0 [ 191.371557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 191.372192] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 191.372906] Call Trace: [ 191.373262] <TASK> [ 191.373621] ? show_regs+0x64/0x70 [ 191.374040] ? __die+0x24/0x70 [ 191.374468] ? page_fault_oops+0x290/0x5b0 [ 191.374875] ? do_user_addr_fault+0x448/0x800 [ 191.375357] ? exc_page_fault+0x7a/0x160 [ 191.375971] ? asm_exc_page_fault+0x27/0x30 [ 191.376416] ? down_write+0x19/0x50 [ 191.376832] ? down_write+0x12/0x50 [ 191.377232] simple_recursive_removal+0x4a/0x2a0 [ 191.377679] ? __pfx_remove_one+0x10/0x10 [ 191.378088] debugfs_remove+0x44/0x70 [ 191.378530] mana_detach+0x17c/0x4f0 [ 191.378950] ? __flush_work+0x1e2/0x3b0 [ 191.379362] ? __cond_resched+0x1a/0x50 [ 191.379787] mana_remove+0xf2/0x1a0 [ 191.380193] mana_gd_shutdown+0x3b/0x70 [ 191.380642] pci_device_shutdown+0x3a/0x80 [ 191.381063] device_shutdown+0x13e/0x230 [ 191.381480] kernel_power_off+0x35/0x80 [ 191.381890] hibernate+0x3c6/0x470 [ 191.382312] state_store+0xcb/0xd0 [ 191.382734] kobj_attr_store+0x12/0x30 [ 191.383211] sysfs_kf_write+0x3e/0x50 [ 191.383640] kernfs_fop_write_iter+0x140/0x1d0 [ 191.384106] vfs_write+0x271/0x440 [ 191.384521] ksys_write+0x72/0xf0 [ 191.384924] __x64_sys_write+0x19/0x20 [ 191.385313] x64_sys_call+0x2b0/0x20b0 [ 191.385736] do_syscall_64+0x79/0x150 [ 191.386146] ? __mod_memcg_lruvec_state+0xe7/0x240 [ 191.386676] ? __lruvec_stat_mod_folio+0x79/0xb0 [ 191.387124] ? __pfx_lru_add+0x10/0x10 [ 191.387515] ? queued_spin_unlock+0x9/0x10 [ 191.387937] ? do_anonymous_page+0x33c/0xa00 [ 191.388374] ? __handle_mm_fault+0xcf3/0x1210 [ 191.388805] ? __count_memcg_events+0xbe/0x180 [ 191.389235] ? handle_mm_fault+0xae/0x300 [ 19 ---truncated--- |
| CVE-2025-21779 | In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC. |
| CVE-2025-21335 | Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege Vulnerability |
| CVE-2025-21334 | Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege Vulnerability |
| CVE-2025-21333 | Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege Vulnerability |
| CVE-2024-6222 | In Docker Desktop before v4.29.0, an attacker who has gained access to the Docker Desktop VM through a container breakout can further escape to the host by passing extensions and dashboard related IPC messages. Docker Desktop v4.29.0 https://docs.docker.com/desktop/release-notes/#4290 fixes the issue on MacOS, Linux and Windows with Hyper-V backend. As exploitation requires "Allow only extensions distributed through the Docker Marketplace" to be disabled, Docker Desktop v4.31.0 https://docs.docker.com/desktop/release-notes/#4310 additionally changes the default configuration to enable this setting by default. |
| CVE-2024-56545 | In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: streamline driver probe to avoid devres issues It was found that unloading 'hid_hyperv' module results in a devres complaint: ... hv_vmbus: unregistering driver hid_hyperv ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0 ... Call Trace: <TASK> ? devres_release_group+0x1f2/0x2c0 ? __warn+0xd1/0x1c0 ? devres_release_group+0x1f2/0x2c0 ? report_bug+0x32a/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? devres_release_group+0x1f2/0x2c0 ? devres_release_group+0x90/0x2c0 ? rcu_is_watching+0x15/0xb0 ? __pfx_devres_release_group+0x10/0x10 hid_device_remove+0xf5/0x220 device_release_driver_internal+0x371/0x540 ? klist_put+0xf3/0x170 bus_remove_device+0x1f1/0x3f0 device_del+0x33f/0x8c0 ? __pfx_device_del+0x10/0x10 ? cleanup_srcu_struct+0x337/0x500 hid_destroy_device+0xc8/0x130 mousevsc_remove+0xd2/0x1d0 [hid_hyperv] device_release_driver_internal+0x371/0x540 driver_detach+0xc5/0x180 bus_remove_driver+0x11e/0x2a0 ? __mutex_unlock_slowpath+0x160/0x5e0 vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus] ... And the issue seems to be that the corresponding devres group is not allocated. Normally, devres_open_group() is called from __hid_device_probe() but Hyper-V HID driver overrides 'hid_dev->driver' with 'mousevsc_hid_driver' stub and basically re-implements __hid_device_probe() by calling hid_parse() and hid_hw_start() but not devres_open_group(). hid_device_probe() does not call __hid_device_probe() for it. Later, when the driver is removed, hid_device_remove() calls devres_release_group() as it doesn't check whether hdev->driver was initially overridden or not. The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure timely release of driver-allocated resources") but the commit itself seems to be correct. Fix the issue by dropping the 'hid_dev->driver' override and using hid_register_driver()/hid_unregister_driver() instead. Alternatively, it would have been possible to rely on the default handling but HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn't seem to work for mousevsc as-is. |
| CVE-2024-49117 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2024-43633 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2024-43624 | Windows Hyper-V Shared Virtual Disk Elevation of Privilege Vulnerability |
| CVE-2024-43575 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2024-43567 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2024-43521 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2024-38235 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2024-38127 | Windows Hyper-V Elevation of Privilege Vulnerability |
| CVE-2024-38080 | Windows Hyper-V Elevation of Privilege Vulnerability |
| CVE-2024-35927 | In the Linux kernel, the following vulnerability has been resolved: drm: Check output polling initialized before disabling In drm_kms_helper_poll_disable() check if output polling support is initialized before disabling polling. If not flag this as a warning. Additionally in drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() calls, that re the callers of these functions, avoid invoking them if polling is not initialized. For drivers like hyperv-drm, that do not initialize connector polling, if suspend is called without this check, it leads to suspend failure with following stack [ 770.719392] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 770.720592] printk: Suspending console(s) (use no_console_suspend to debug) [ 770.948823] ------------[ cut here ]------------ [ 770.948824] WARNING: CPU: 1 PID: 17197 at kernel/workqueue.c:3162 __flush_work.isra.0+0x212/0x230 [ 770.948831] Modules linked in: rfkill nft_counter xt_conntrack xt_owner udf nft_compat crc_itu_t nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink vfat fat mlx5_ib ib_uverbs ib_core mlx5_core intel_rapl_msr intel_rapl_common kvm_amd ccp mlxfw kvm psample hyperv_drm tls drm_shmem_helper drm_kms_helper irqbypass pcspkr syscopyarea sysfillrect sysimgblt hv_balloon hv_utils joydev drm fuse xfs libcrc32c pci_hyperv pci_hyperv_intf sr_mod sd_mod cdrom t10_pi sg hv_storvsc scsi_transport_fc hv_netvsc serio_raw hyperv_keyboard hid_hyperv crct10dif_pclmul crc32_pclmul crc32c_intel hv_vmbus ghash_clmulni_intel dm_mirror dm_region_hash dm_log dm_mod [ 770.948863] CPU: 1 PID: 17197 Comm: systemd-sleep Not tainted 5.14.0-362.2.1.el9_3.x86_64 #1 [ 770.948865] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 770.948866] RIP: 0010:__flush_work.isra.0+0x212/0x230 [ 770.948869] Code: 8b 4d 00 4c 8b 45 08 89 ca 48 c1 e9 04 83 e2 08 83 e1 0f 83 ca 02 89 c8 48 0f ba 6d 00 03 e9 25 ff ff ff 0f 0b e9 4e ff ff ff <0f> 0b 45 31 ed e9 44 ff ff ff e8 8f 89 b2 00 66 66 2e 0f 1f 84 00 [ 770.948870] RSP: 0018:ffffaf4ac213fb10 EFLAGS: 00010246 [ 770.948871] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8c992857 [ 770.948872] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff9aad82b00330 [ 770.948873] RBP: ffff9aad82b00330 R08: 0000000000000000 R09: ffff9aad87ee3d10 [ 770.948874] R10: 0000000000000200 R11: 0000000000000000 R12: ffff9aad82b00330 [ 770.948874] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 [ 770.948875] FS: 00007ff1b2f6bb40(0000) GS:ffff9aaf37d00000(0000) knlGS:0000000000000000 [ 770.948878] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 770.948878] CR2: 0000555f345cb666 CR3: 00000001462dc005 CR4: 0000000000370ee0 [ 770.948879] Call Trace: [ 770.948880] <TASK> [ 770.948881] ? show_trace_log_lvl+0x1c4/0x2df [ 770.948884] ? show_trace_log_lvl+0x1c4/0x2df [ 770.948886] ? __cancel_work_timer+0x103/0x190 [ 770.948887] ? __flush_work.isra.0+0x212/0x230 [ 770.948889] ? __warn+0x81/0x110 [ 770.948891] ? __flush_work.isra.0+0x212/0x230 [ 770.948892] ? report_bug+0x10a/0x140 [ 770.948895] ? handle_bug+0x3c/0x70 [ 770.948898] ? exc_invalid_op+0x14/0x70 [ 770.948899] ? asm_exc_invalid_op+0x16/0x20 [ 770.948903] ? __flush_work.isra.0+0x212/0x230 [ 770.948905] __cancel_work_timer+0x103/0x190 [ 770.948907] ? _raw_spin_unlock_irqrestore+0xa/0x30 [ 770.948910] drm_kms_helper_poll_disable+0x1e/0x40 [drm_kms_helper] [ 770.948923] drm_mode_config_helper_suspend+0x1c/0x80 [drm_kms_helper] [ 770.948933] ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus] [ 770.948942] hyperv_vmbus_suspend+0x17/0x40 [hyperv_drm] [ 770.948944] ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus] [ 770.948951] dpm_run_callback+0x4c/0x140 [ 770.948954] __device_suspend_noir ---truncated--- |
| CVE-2024-30092 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2024-30017 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2024-30011 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2024-30010 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2024-29064 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2024-21408 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2024-21407 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2024-20700 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2024-20699 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2024-20684 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2024-20659 | Windows Hyper-V Security Feature Bypass Vulnerability |
| CVE-2023-36908 | Windows Hyper-V Information Disclosure Vulnerability |
| CVE-2023-36427 | Windows Hyper-V Elevation of Privilege Vulnerability |
| CVE-2023-36408 | Windows Hyper-V Elevation of Privilege Vulnerability |
| CVE-2023-36407 | Windows Hyper-V Elevation of Privilege Vulnerability |
| CVE-2023-36406 | Windows Hyper-V Information Disclosure Vulnerability |
| CVE-2023-32013 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2023-23411 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2022-49986 | In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it doesn't need to make forward progress under memory pressure. Marking this workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following warning: [ 14.506347] ------------[ cut here ]------------ [ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn [ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip-> [ 14.506408] Call Trace: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414] __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418] cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421] del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427] device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429] bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432] __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437] worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [ 14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]--- |
| CVE-2022-49726 | In the Linux kernel, the following vulnerability has been resolved: clocksource: hyper-v: unexport __init-annotated hv_init_clocksource() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, arch/x86/kernel/cpu/mshyperv.c is never compiled as modular. (CONFIG_HYPERVISOR_GUEST is boolean) |
| CVE-2022-49098 | 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. |
| CVE-2022-49054 | In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Deactivate sysctl_record_panic_msg by default in isolated guests hv_panic_page might contain guest-sensitive information, do not dump it over to Hyper-V by default in isolated guests. While at it, update some comments in hyperv_{panic,die}_event(). |
| CVE-2022-48919 | In the Linux kernel, the following vulnerability has been resolved: cifs: fix double free race when mount fails in cifs_get_root() When cifs_get_root() fails during cifs_smb3_do_mount() we call deactivate_locked_super() which eventually will call delayed_free() which will free the context. In this situation we should not proceed to enter the out: section in cifs_smb3_do_mount() and free the same resources a second time. [Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0 [Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.17.0-rc3+ #4 [Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019 [Thu Feb 10 12:59:06 2022] Call Trace: [Thu Feb 10 12:59:06 2022] <IRQ> [Thu Feb 10 12:59:06 2022] dump_stack_lvl+0x5d/0x78 [Thu Feb 10 12:59:06 2022] print_address_description.constprop.0+0x24/0x150 [Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] kasan_report.cold+0x7d/0x117 [Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] __asan_load8+0x86/0xa0 [Thu Feb 10 12:59:06 2022] rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] rcu_core+0x547/0xca0 [Thu Feb 10 12:59:06 2022] ? call_rcu+0x3c0/0x3c0 [Thu Feb 10 12:59:06 2022] ? __this_cpu_preempt_check+0x13/0x20 [Thu Feb 10 12:59:06 2022] ? lock_is_held_type+0xea/0x140 [Thu Feb 10 12:59:06 2022] rcu_core_si+0xe/0x10 [Thu Feb 10 12:59:06 2022] __do_softirq+0x1d4/0x67b [Thu Feb 10 12:59:06 2022] __irq_exit_rcu+0x100/0x150 [Thu Feb 10 12:59:06 2022] irq_exit_rcu+0xe/0x30 [Thu Feb 10 12:59:06 2022] sysvec_hyperv_stimer0+0x9d/0xc0 ... [Thu Feb 10 12:59:07 2022] Freed by task 58179: [Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50 [Thu Feb 10 12:59:07 2022] kasan_set_track+0x25/0x30 [Thu Feb 10 12:59:07 2022] kasan_set_free_info+0x24/0x40 [Thu Feb 10 12:59:07 2022] ____kasan_slab_free+0x137/0x170 [Thu Feb 10 12:59:07 2022] __kasan_slab_free+0x12/0x20 [Thu Feb 10 12:59:07 2022] slab_free_freelist_hook+0xb3/0x1d0 [Thu Feb 10 12:59:07 2022] kfree+0xcd/0x520 [Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0x149/0xbe0 [cifs] [Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs] [Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140 [Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0 [Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210 [Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0 [Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae [Thu Feb 10 12:59:07 2022] Last potentially related work creation: [Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50 [Thu Feb 10 12:59:07 2022] __kasan_record_aux_stack+0xb6/0xc0 [Thu Feb 10 12:59:07 2022] kasan_record_aux_stack_noalloc+0xb/0x10 [Thu Feb 10 12:59:07 2022] call_rcu+0x76/0x3c0 [Thu Feb 10 12:59:07 2022] cifs_umount+0xce/0xe0 [cifs] [Thu Feb 10 12:59:07 2022] cifs_kill_sb+0xc8/0xe0 [cifs] [Thu Feb 10 12:59:07 2022] deactivate_locked_super+0x5d/0xd0 [Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0xab9/0xbe0 [cifs] [Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs] [Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140 [Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0 [Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210 [Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0 [Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae |
| CVE-2022-44682 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2022-41094 | Windows Hyper-V Elevation of Privilege Vulnerability |
| CVE-2022-38015 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2022-37979 | Windows Hyper-V Elevation of Privilege Vulnerability |
| CVE-2022-35751 | Windows Hyper-V Elevation of Privilege Vulnerability |
| CVE-2022-34696 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2022-30223 | Windows Hyper-V Information Disclosure Vulnerability |
| CVE-2022-30163 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2022-29106 | Windows Hyper-V Shared Virtual Disk Elevation of Privilege Vulnerability |
| CVE-2022-26785 | Windows Hyper-V Shared Virtual Hard Disks Information Disclosure Vulnerability |
| CVE-2022-26783 | Windows Hyper-V Shared Virtual Hard Disks Information Disclosure Vulnerability |
| CVE-2022-24539 | Windows Hyper-V Shared Virtual Hard Disks Information Disclosure Vulnerability |
| CVE-2022-24537 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2022-24490 | Windows Hyper-V Shared Virtual Hard Disks Information Disclosure Vulnerability |
| CVE-2022-24466 | Windows Hyper-V Security Feature Bypass Vulnerability |
| CVE-2022-23268 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2022-23257 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2022-22713 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2022-22712 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2022-22042 | Windows Hyper-V Information Disclosure Vulnerability |
| CVE-2022-22009 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2022-22008 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2022-21995 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2022-21975 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2022-21905 | Windows Hyper-V Security Feature Bypass Vulnerability |
| CVE-2022-21901 | Windows Hyper-V Elevation of Privilege Vulnerability |
| CVE-2022-21900 | Windows Hyper-V Security Feature Bypass Vulnerability |
| CVE-2022-21847 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2021-47217 | In the Linux kernel, the following vulnerability has been resolved: x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails Check for a valid hv_vp_index array prior to derefencing hv_vp_index when setting Hyper-V's TSC change callback. If Hyper-V setup failed in hyperv_init(), the kernel will still report that it's running under Hyper-V, but will have silently disabled nearly all functionality. BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:set_hv_tscchange_cb+0x15/0xa0 Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08 ... Call Trace: kvm_arch_init+0x17c/0x280 kvm_init+0x31/0x330 vmx_init+0xba/0x13a do_one_initcall+0x41/0x1c0 kernel_init_freeable+0x1f2/0x23b kernel_init+0x16/0x120 ret_from_fork+0x22/0x30 |
| CVE-2021-43246 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2021-42284 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2021-42274 | Windows Hyper-V Discrete Device Assignment (DDA) Denial of Service Vulnerability |
| CVE-2021-40461 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2021-38672 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2021-37841 | Docker Desktop before 3.6.0 suffers from incorrect access control. If a low-privileged account is able to access the server running the Windows containers, it can lead to a full container compromise in both process isolation and Hyper-V isolation modes. This security issue leads an attacker with low privilege to read, write and possibly even execute code inside the containers. |
| CVE-2021-34450 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2021-33758 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2021-33755 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2021-31977 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2021-30178 | An issue was discovered in the Linux kernel through 5.11.11. synic_get in arch/x86/kvm/hyperv.c has a NULL pointer dereference for certain accesses to the SynIC Hyper-V context, aka CID-919f4ebc5987. |
| CVE-2021-28476 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2021-28444 | Windows Hyper-V Security Feature Bypass Vulnerability |
| CVE-2021-28441 | Windows Hyper-V Information Disclosure Vulnerability |
| CVE-2021-28314 | Windows Hyper-V Elevation of Privilege Vulnerability |
| CVE-2021-26867 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2021-26416 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2021-25140 | A potential security vulnerability has been identified in the HPE Moonshot Provisioning Manager v1.20. The HPE Moonshot Provisioning Manager is an application that is installed in a VMWare or Microsoft Hyper-V environment that is used to setup and configure an HPE Moonshot 1500 chassis. This vulnerability could be remotely exploited by an unauthenticated user to cause a directory traversal in user supplied input to the `khuploadfile.cgi` CGI ELF. The directory traversal could lead to Remote Code Execution, Denial of Service, and/or compromise system integrity. **Note:** HPE recommends that customers discontinue the use of the HPE Moonshot Provisioning Manager. The HPE Moonshot Provisioning Manager application is discontinued, no longer supported, is not available to download from the HPE Support Center, and no patch is available. |
| CVE-2021-25139 | A potential security vulnerability has been identified in the HPE Moonshot Provisioning Manager v1.20. The HPE Moonshot Provisioning Manager is an application that is installed in a VMWare or Microsoft Hyper-V environment that is used to setup and configure an HPE Moonshot 1500 chassis. This vulnerability could be remotely exploited by an unauthenticated user to cause a stack based buffer overflow using user supplied input to the `khuploadfile.cgi` CGI ELF. The stack based buffer overflow could lead to Remote Code Execution, Denial of Service, and/or compromise system integrity. **Note:** HPE recommends that customers discontinue the use of the HPE Moonshot Provisioning Manager. The HPE Moonshot Provisioning Manager application is discontinued, no longer supported, is not available to download from the HPE Support Center, and no patch is available. |
| CVE-2021-1704 | Windows Hyper-V Elevation of Privilege Vulnerability |
| CVE-2021-1692 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2021-1691 | Windows Hyper-V Denial of Service Vulnerability |
| CVE-2020-6103 | An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.dll 26.20.15019.19000. An attacker can provide a a specially crafted shader file to trigger this vulnerability, resulting in code execution. This vulnerability can be triggered from a HYPER-V guest using the RemoteFX feature, leading to executing the vulnerable code on the HYPER-V host (inside of the rdvgm.exe process). Theoretically this vulnerability could be also triggered from web browser (using webGL and webassembly). |
| CVE-2020-6102 | An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.dll 26.20.15019.19000. An attacker can provide a a specially crafted shader file to trigger this vulnerability, resulting in code execution. This vulnerability can be triggered from a HYPER-V guest using the RemoteFX feature, leading to executing the vulnerable code on the HYPER-V host (inside of the rdvgm.exe process). Theoretically this vulnerability could be also triggered from web browser (using webGL and webassembly). |
| CVE-2020-6101 | An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.dll 26.20.15019.19000. An attacker can provide a specially crafted shader file to trigger this vulnerability, resulting in code execution. This vulnerability can be triggered from a HYPER-V guest using the RemoteFX feature, leading to executing the vulnerable code on the HYPER-V host (inside of the rdvgm.exe process). Theoretically this vulnerability could be also triggered from web browser (using webGL and webassembly). |
| CVE-2020-6100 | An exploitable memory corruption vulnerability exists in AMD atidxx64.dll 26.20.15019.19000 graphics driver. A specially crafted pixel shader can cause memory corruption vulnerability. An attacker can provide a specially crafted shader file to trigger this vulnerability. This vulnerability potentially could be triggered from guest machines running virtualization environments (ie. VMware, qemu, VirtualBox etc.) in order to perform guest-to-host escape - as it was demonstrated before (TALOS-2018-0533, TALOS-2018-0568, etc.). Theoretically this vulnerability could be also triggered from web browser (using webGL and webassembly). This vulnerability was triggered from HYPER-V guest using RemoteFX feature leading to executing the vulnerable code on the HYPER-V host (inside of the rdvgm.exe process). |
| CVE-2020-24623 | A potential security vulnerability has been identified in Hewlett Packard Enterprise Universal API Framework. The vulnerability could be remotely exploited to allow SQL injection in HPE Universal API Framework for VMware Esxi v2.5.2 and HPE Universal API Framework for Microsoft Hyper-V (VHD). |
| CVE-2020-17095 | Windows Hyper-V Remote Code Execution Vulnerability |
| CVE-2020-17040 | Windows Hyper-V Security Feature Bypass Vulnerability |
| CVE-2020-16891 | <p>A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system. To exploit the vulnerability, an attacker could run a specially crafted application on a guest operating system that could cause the Hyper-V host operating system to execute arbitrary code.</p> <p>An attacker who successfully exploited the vulnerability could execute arbitrary code on the host operating system.</p> <p>The security update addresses the vulnerability by correcting how Hyper-V validates guest operating system user input.</p> |
| CVE-2020-1243 | <p>A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate specific malicious data from a user on a guest operating system.</p> <p>To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application.</p> <p>The security update addresses the vulnerability by resolving the conditions where Hyper-V would fail to handle these requests.</p> |
| CVE-2020-1080 | <p>An elevation of privilege vulnerability exists when Windows Hyper-V on a host server fails to properly handle objects in memory. An attacker who successfully exploited these vulnerabilities could gain elevated privileges on a target operating system.</p> <p>This vulnerability by itself does not allow arbitrary code to be run. However, this vulnerability could be used in conjunction with one or more vulnerabilities (e.g. a remote code execution vulnerability and another elevation of privilege) that could take advantage of the elevated privileges when running.</p> <p>The update addresses the vulnerabilities by correcting how Windows Hyper-V handles objects in memory.</p> |
| CVE-2020-1047 | <p>An elevation of privilege vulnerability exists when Windows Hyper-V on a host server fails to properly handle objects in memory. An attacker who successfully exploited these vulnerabilities could gain elevated privileges on a target operating system.</p> <p>This vulnerability by itself does not allow arbitrary code to be run. However, this vulnerability could be used in conjunction with one or more vulnerabilities (e.g. a remote code execution vulnerability and another elevation of privilege) that could take advantage of the elevated privileges when running.</p> <p>The update addresses the vulnerabilities by correcting how Windows Hyper-V handles objects in memory.</p> |
| CVE-2020-1043 | A remote code execution vulnerability exists when Hyper-V RemoteFX vGPU on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Hyper-V RemoteFX vGPU Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2020-1032, CVE-2020-1036, CVE-2020-1040, CVE-2020-1041, CVE-2020-1042. |
| CVE-2020-1042 | A remote code execution vulnerability exists when Hyper-V RemoteFX vGPU on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Hyper-V RemoteFX vGPU Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2020-1032, CVE-2020-1036, CVE-2020-1040, CVE-2020-1041, CVE-2020-1043. |
| CVE-2020-1041 | A remote code execution vulnerability exists when Hyper-V RemoteFX vGPU on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Hyper-V RemoteFX vGPU Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2020-1032, CVE-2020-1036, CVE-2020-1040, CVE-2020-1042, CVE-2020-1043. |
| CVE-2020-1040 | A remote code execution vulnerability exists when Hyper-V RemoteFX vGPU on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Hyper-V RemoteFX vGPU Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2020-1032, CVE-2020-1036, CVE-2020-1041, CVE-2020-1042, CVE-2020-1043. |
| CVE-2020-1036 | A remote code execution vulnerability exists when Hyper-V RemoteFX vGPU on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Hyper-V RemoteFX vGPU Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2020-1032, CVE-2020-1040, CVE-2020-1041, CVE-2020-1042, CVE-2020-1043. |
| CVE-2020-1032 | A remote code execution vulnerability exists when Hyper-V RemoteFX vGPU on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Hyper-V RemoteFX vGPU Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2020-1036, CVE-2020-1040, CVE-2020-1041, CVE-2020-1042, CVE-2020-1043. |
| CVE-2020-0918 | An elevation of privilege vulnerability exists when Windows Hyper-V on a host server fails to properly handle objects in memory, aka 'Windows Hyper-V Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2020-0917. |
| CVE-2020-0917 | An elevation of privilege vulnerability exists when Windows Hyper-V on a host server fails to properly handle objects in memory, aka 'Windows Hyper-V Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2020-0918. |
| CVE-2020-0910 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Windows Hyper-V Remote Code Execution Vulnerability'. |
| CVE-2020-0909 | A denial of service vulnerability exists when Hyper-V on a Windows Server fails to properly handle specially crafted network packets.To exploit the vulnerability, an attacker would send specially crafted network packets to the Hyper-V Server.The security update addresses the vulnerability by resolving the conditions where Hyper-V would fail to properly handle these network packets., aka 'Windows Hyper-V Denial of Service Vulnerability'. |
| CVE-2020-0904 | <p>A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate specific malicious data from a user on a guest operating system.</p> <p>To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application.</p> <p>The security update addresses the vulnerability by resolving the conditions where Hyper-V would fail to handle these requests.</p> |
| CVE-2020-0890 | <p>A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate specific malicious data from a user on a guest operating system.</p> <p>To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application.</p> <p>The security update addresses the vulnerability by resolving the conditions where Hyper-V would fail to handle these requests.</p> |
| CVE-2020-0751 | A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate specific malicious data from a user on a guest operating system.To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application.The security update addresses the vulnerability by resolving the conditions where Hyper-V would fail to handle these requests., aka 'Windows Hyper-V Denial of Service Vulnerability'. This CVE ID is unique from CVE-2020-0661. |
| CVE-2020-0661 | A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate input from a privileged user on a guest operating system, aka 'Windows Hyper-V Denial of Service Vulnerability'. This CVE ID is unique from CVE-2020-0751. |
| CVE-2020-0617 | A denial of service vulnerability exists when Microsoft Hyper-V Virtual PCI on a host server fails to properly validate input from a privileged user on a guest operating system, aka 'Hyper-V Denial of Service Vulnerability'. |
| CVE-2019-1599 | A vulnerability in the network stack of Cisco NX-OS Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on the affected device. The vulnerability is due to an issue with allocating and freeing memory buffers in the network stack. An attacker could exploit this vulnerability by sending crafted TCP streams to an affected device in a sustained way. A successful exploit could cause the network stack of an affected device to run out of available buffers, impairing operations of control plane and management plane protocols, resulting in a DoS condition. Note: This vulnerability can be triggered only by traffic that is destined to an affected device and cannot be exploited using traffic that transits an affected device. Nexus 1000V Switch for Microsoft Hyper-V is affected in versions prior to 5.2(1)SM3(2.1). Nexus 1000V Switch for VMware vSphere is affected in versions prior to 5.2(1)SV3(4.1a). Nexus 3000 Series Switches are affected in versions prior to 7.0(3)I7(6) and 9.2(2). Nexus 3500 Platform Switches are affected in versions prior to 6.0(2)A8(11), 7.0(3)I7(6), and 9.2(2). Nexus 3600 Platform Switches are affected in versions prior to 7.0(3)F3(5) and 9.2(2). Nexus 5500, 5600, and 6000 Series Switches are affected in versions prior to 7.1(5)N1(1b) and 7.3(5)N1(1). Nexus 7000 and 7700 Series Switches are affected in versions prior to 6.2(22. Nexus 9500 R-Series Line Cards and Fabric Modules are affected in versions prior to 7.0(3)F3(5) and 9.2(2). UCS 6200 and 6300 Series Fabric Interconnect are affected in versions prior to 3.2(3j) and 4.0(2a). UCS 6400 Series Fabric Interconnect are affected in versions prior to 4.0(2a). |
| CVE-2019-1471 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Windows Hyper-V Remote Code Execution Vulnerability'. |
| CVE-2019-1470 | An information disclosure vulnerability exists when Windows Hyper-V on a host operating system fails to properly validate input from an authenticated user on a guest operating system, aka 'Windows Hyper-V Information Disclosure Vulnerability'. |
| CVE-2019-1399 | A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate input from a privileged user on a guest operating system, aka 'Windows Hyper-V Denial of Service Vulnerability'. This CVE ID is unique from CVE-2019-0712, CVE-2019-1309, CVE-2019-1310. |
| CVE-2019-1398 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Windows Hyper-V Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2019-1389, CVE-2019-1397. |
| CVE-2019-1397 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Windows Hyper-V Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2019-1389, CVE-2019-1398. |
| CVE-2019-1389 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Windows Hyper-V Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2019-1397, CVE-2019-1398. |
| CVE-2019-1310 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system, aka 'Windows Hyper-V Denial of Service Vulnerability'. This CVE ID is unique from CVE-2019-0712, CVE-2019-1309, CVE-2019-1399. |
| CVE-2019-1309 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system, aka 'Windows Hyper-V Denial of Service Vulnerability'. This CVE ID is unique from CVE-2019-0712, CVE-2019-1310, CVE-2019-1399. |
| CVE-2019-1254 | An information disclosure vulnerability exists when Windows Hyper-V writes uninitialized memory to disk, aka 'Windows Hyper-V Information Disclosure Vulnerability'. |
| CVE-2019-1230 | An information disclosure vulnerability exists when the Windows Hyper-V Network Switch on a host operating system fails to properly validate input from an authenticated user on a guest operating system, aka 'Hyper-V Information Disclosure Vulnerability'. |
| CVE-2019-0966 | A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate input from a privileged user on a guest operating system, aka 'Windows Hyper-V Denial of Service Vulnerability'. |
| CVE-2019-0965 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system. To exploit the vulnerability, an attacker could run a specially crafted application on a guest operating system that could cause the Hyper-V host operating system to execute arbitrary code. An attacker who successfully exploited the vulnerability could execute arbitrary code on the host operating system. The security update addresses the vulnerability by correcting how Hyper-V validates guest operating system user input. |
| CVE-2019-0928 | A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate input from a privileged user on a guest operating system, aka 'Windows Hyper-V Denial of Service Vulnerability'. |
| CVE-2019-0886 | An information disclosure vulnerability exists when Windows Hyper-V on a host operating system fails to properly validate input from an authenticated user on a guest operating system, aka 'Windows Hyper-V Information Disclosure Vulnerability'. |
| CVE-2019-0723 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system. An attacker who successfully exploited the vulnerability could cause the host server to crash. To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application that causes a host machine to crash. The update addresses the vulnerability by modifying how virtual machines access the Hyper-V Network Switch. |
| CVE-2019-0722 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system. To exploit the vulnerability, an attacker could run a specially crafted application on a guest operating system that could cause the Hyper-V host operating system to execute arbitrary code. An attacker who successfully exploited the vulnerability could execute arbitrary code on the host operating system. The security update addresses the vulnerability by correcting how Hyper-V validates guest operating system user input. |
| CVE-2019-0721 | A remote code execution vulnerability exists when Windows Hyper-V Network Switch on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Hyper-V Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2019-0719. |
| CVE-2019-0720 | A remote code execution vulnerability exists when Windows Hyper-V Network Switch on a host server fails to properly validate input from an authenticated user on a guest operating system. To exploit the vulnerability, an attacker could run a specially crafted application on a guest operating system that could cause the Hyper-V host operating system to execute arbitrary code. An attacker who successfully exploited the vulnerability could execute arbitrary code on the host operating system. The security update addresses the vulnerability by correcting how Windows Hyper-V Network Switch validates guest operating system network traffic. |
| CVE-2019-0719 | A remote code execution vulnerability exists when Windows Hyper-V Network Switch on a host server fails to properly validate input from an authenticated user on a guest operating system, aka 'Hyper-V Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2019-0721. |
| CVE-2019-0718 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system. An attacker who successfully exploited the vulnerability could cause the host server to crash. To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application that causes a host machine to crash. The update addresses the vulnerability by modifying how virtual machines access the Hyper-V Network Switch. |
| CVE-2019-0717 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system. An attacker who successfully exploited the vulnerability could cause the host server to crash. To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application that causes a host machine to crash. The update addresses the vulnerability by modifying how virtual machines access the Hyper-V Network Switch. |
| CVE-2019-0715 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system. An attacker who successfully exploited the vulnerability could cause the host server to crash. To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application that causes a host machine to crash. The update addresses the vulnerability by modifying how virtual machines access the Hyper-V Network Switch. |
| CVE-2019-0714 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system. An attacker who successfully exploited the vulnerability could cause the host server to crash. To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application that causes a host machine to crash. The update addresses the vulnerability by modifying how virtual machines access the Hyper-V Network Switch. |
| CVE-2019-0713 | A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate input from a privileged user on a guest operating system. To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application that causes a host machine to crash. To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application. The security update addresses the vulnerability by resolving a number of conditions where Hyper-V would fail to prevent a guest operating system from sending malicious requests. |
| CVE-2019-0712 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system, aka 'Windows Hyper-V Denial of Service Vulnerability'. This CVE ID is unique from CVE-2019-1309, CVE-2019-1310, CVE-2019-1399. |
| CVE-2019-0711 | A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate input from a privileged user on a guest operating system. To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application that causes a host machine to crash. To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application. The security update addresses the vulnerability by resolving a number of conditions where Hyper-V would fail to prevent a guest operating system from sending malicious requests. |
| CVE-2019-0710 | A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate input from a privileged user on a guest operating system. To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application that causes a host machine to crash. To exploit the vulnerability, an attacker who already has a privileged account on a guest operating system, running as a virtual machine, could run a specially crafted application. The security update addresses the vulnerability by resolving a number of conditions where Hyper-V would fail to prevent a guest operating system from sending malicious requests. |
| CVE-2019-0709 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system. To exploit the vulnerability, an attacker could run a specially crafted application on a guest operating system that could cause the Hyper-V host operating system to execute arbitrary code. An attacker who successfully exploited the vulnerability could execute arbitrary code on the host operating system. The security update addresses the vulnerability by correcting how Hyper-V validates guest operating system user input. |
| CVE-2019-0701 | A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate input from a privileged user on a guest operating system, aka 'Windows Hyper-V Denial of Service Vulnerability'. This CVE ID is unique from CVE-2019-0690, CVE-2019-0695. |
| CVE-2019-0695 | A denial of service vulnerability exists when Microsoft Hyper-V on a host server fails to properly validate input from a privileged user on a guest operating system, aka 'Windows Hyper-V Denial of Service Vulnerability'. This CVE ID is unique from CVE-2019-0690, CVE-2019-0701. |
| CVE-2019-0690 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system, aka 'Windows Hyper-V Denial of Service Vulnerability'. This CVE ID is unique from CVE-2019-0695, CVE-2019-0701. |
| CVE-2019-0635 | An information disclosure vulnerability exists when Windows Hyper-V on a host operating system fails to properly validate input from an authenticated user on a guest operating system, aka 'Windows Hyper-V Information Disclosure Vulnerability'. |
| CVE-2019-0620 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system. To exploit the vulnerability, an attacker could run a specially crafted application on a guest operating system that could cause the Hyper-V host operating system to execute arbitrary code. An attacker who successfully exploited the vulnerability could execute arbitrary code on the host operating system. The security update addresses the vulnerability by correcting how Hyper-V validates guest operating system user input. |
| CVE-2019-0551 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system, aka "Windows Hyper-V Remote Code Execution Vulnerability." This affects Windows Server 2016, Windows 10, Windows Server 2019, Windows 10 Servers. This CVE ID is unique from CVE-2019-0550. |
| CVE-2019-0550 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system, aka "Windows Hyper-V Remote Code Execution Vulnerability." This affects Windows 10 Servers, Windows 10, Windows Server 2019. This CVE ID is unique from CVE-2019-0551. |
| CVE-2018-8490 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system, aka "Windows Hyper-V Remote Code Execution Vulnerability." This affects Windows Server 2016, Windows 10, Windows Server 2019, Windows 10 Servers. This CVE ID is unique from CVE-2018-8489. |
| CVE-2018-8489 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system, aka "Windows Hyper-V Remote Code Execution Vulnerability." This affects Windows 7, Windows Server 2012 R2, Windows RT 8.1, Windows Server 2008, Windows Server 2019, Windows Server 2012, Windows 8.1, Windows Server 2016, Windows Server 2008 R2, Windows 10, Windows 10 Servers. This CVE ID is unique from CVE-2018-8490. |
| CVE-2018-8439 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system, aka "Windows Hyper-V Remote Code Execution Vulnerability." This affects Windows Server 2012 R2, Windows RT 8.1, Windows Server 2016, Windows 8.1, Windows 10, Windows 10 Servers. This CVE ID is unique from CVE-2018-0965. |
| CVE-2018-8438 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system, aka "Windows Hyper-V Denial of Service Vulnerability." This affects Windows Server 2012 R2, Windows RT 8.1, Windows Server 2016, Windows 8.1, Windows 10, Windows 10 Servers. This CVE ID is unique from CVE-2018-8436, CVE-2018-8437. |
| CVE-2018-8437 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system, aka "Windows Hyper-V Denial of Service Vulnerability." This affects Windows 10, Windows 10 Servers. This CVE ID is unique from CVE-2018-8436, CVE-2018-8438. |
| CVE-2018-8436 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system, aka "Windows Hyper-V Denial of Service Vulnerability." This affects Windows 10, Windows 10 Servers. This CVE ID is unique from CVE-2018-8437, CVE-2018-8438. |
| CVE-2018-8435 | A security feature bypass vulnerability exists when Windows Hyper-V BIOS loader fails to provide a high-entropy source, aka "Windows Hyper-V Security Feature Bypass Vulnerability." This affects Windows Server 2016, Windows 10, Windows 10 Servers. |
| CVE-2018-8434 | An information disclosure vulnerability exists when Windows Hyper-V on a host operating system fails to properly validate input from an authenticated user on a guest operating system, aka "Windows Hyper-V Information Disclosure Vulnerability." This affects Windows 7, Windows Server 2012 R2, Windows RT 8.1, Windows Server 2008, Windows Server 2012, Windows 8.1, Windows Server 2016, Windows Server 2008 R2, Windows 10, Windows 10 Servers. |
| CVE-2018-8219 | An elevation of privilege vulnerability exists when Windows Hyper-V instruction emulation fails to properly enforce privilege levels, aka "Hypervisor Code Integrity Elevation of Privilege Vulnerability." This affects Windows Server 2016, Windows 10, Windows 10 Servers. |
| CVE-2018-8218 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch on a host server fails to properly validate input from a privileged user on a guest operating system, aka "Windows Hyper-V Denial of Service Vulnerability." This affects Windows 10, Windows 10 Servers. |
| CVE-2018-0965 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system, aka "Windows Hyper-V Remote Code Execution Vulnerability." This affects Windows Server 2016, Windows 10, Windows 10 Servers. This CVE ID is unique from CVE-2018-8439. |
| CVE-2018-0964 | An information disclosure vulnerability exists when Windows Hyper-V on a host operating system fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Information Disclosure Vulnerability." This affects Windows 10, Windows 10 Servers. This CVE ID is unique from CVE-2018-0957. |
| CVE-2018-0961 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate vSMB packet data, aka "Hyper-V vSMB Remote Code Execution Vulnerability." This affects Windows Server 2016, Windows 10, Windows 10 Servers. |
| CVE-2018-0959 | A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Remote Code Execution Vulnerability." This affects Windows 7, Windows Server 2012 R2, Windows RT 8.1, Windows Server 2008, Windows Server 2012, Windows 8.1, Windows Server 2016, Windows Server 2008 R2, Windows 10, Windows 10 Servers. |
| CVE-2018-0957 | An information disclosure vulnerability exists when Windows Hyper-V on a host operating system fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Information Disclosure Vulnerability." This affects Windows Server 2012 R2, Windows RT 8.1, Windows Server 2016, Windows 8.1, Windows 10, Windows 10 Servers. This CVE ID is unique from CVE-2018-0964. |
| CVE-2018-0888 | The Microsoft Hyper-V Network Switch in 64-bit versions of Microsoft Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 and R2, Windows 10 Gold, 1511, 1607, 1703, and 1709, Windows Server 2016 and Windows Server, version 1709 allows an information disclosure vulnerability due to how guest operating system input is validated, aka "Hyper-V Information Disclosure Vulnerability". |
| CVE-2018-0885 | The Microsoft Hyper-V Network Switch in 64-bit versions of Microsoft Windows Server 2008 SP2 and R2 SP1, Windows Server 2012 and R2, Windows 10 Gold, 1511, 1607, 1703, and 1709, Windows Server 2016 and Windows Server, version 1709 allows a denial of service vulnerability due to how input from a privileged user on a guest operating system is validated, aka "Hyper-V Denial of Service Vulnerability". |
| CVE-2017-8714 | The Windows Hyper-V component on Microsoft Windows 8.1, Windows Server 2012 Gold and R2,, Windows 10 1607, and Windows Server 2016 allows a remote code execution vulnerability when it fails to properly validate input from an authenticated user on a guest operating system, aka "Remote Desktop Virtual Host Remote Code Execution Vulnerability". |
| CVE-2017-8713 | The Windows Hyper-V component on Microsoft Windows Windows 8.1, Windows Server 2012 Gold and R2, Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 allows an information disclosure vulnerability when it fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Information Disclosure Vulnerability". This CVE ID is unique from CVE-2017-8707, CVE-2017-8711, CVE-2017-8712, and CVE-2017-8706. |
| CVE-2017-8712 | The Windows Hyper-V component on Microsoft Windows 10 1607, 1703, and Windows Server 2016 allows an information disclosure vulnerability when it fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Information Disclosure Vulnerability". This CVE ID is unique from CVE-2017-8707, CVE-2017-8711, CVE-2017-8706, and CVE-2017-8713. |
| CVE-2017-8711 | The Windows Hyper-V component on Microsoft Windows 10 1607 and Windows Server 2016 allows an information disclosure vulnerability when it fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Information Disclosure Vulnerability". This CVE ID is unique from CVE-2017-8707, CVE-2017-8706, CVE-2017-8712, and CVE-2017-8713. |
| CVE-2017-8707 | The Windows Hyper-V component on Microsoft Windows Server 2008 SP2 and R2 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 allows an information disclosure vulnerability when it fails to properly validate input from an authenticated user on a guest operating system, aka Hyper-V Information Disclosure Vulnerability". This CVE ID is unique from CVE-2017-8706, CVE-2017-8711, CVE-2017-8712, and CVE-2017-8713. |
| CVE-2017-8706 | The Windows Hyper-V component on Microsoft Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 allows an information disclosure vulnerability when it fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Information Disclosure Vulnerability". This CVE ID is unique from CVE-2017-8707, CVE-2017-8711, CVE-2017-8712, and CVE-2017-8713. |
| CVE-2017-8704 | The Windows Hyper-V component on Microsoft Windows 10 1607 and Windows Server 2016 allows a denial of service vulnerability when it fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Denial of Service Vulnerability". |
| CVE-2017-8664 | Windows Hyper-V in Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 allows a remote code execution vulnerability when it fails to properly validate input from a privileged user on a guest operating system, aka "Windows Hyper-V Remote Code Execution Vulnerability". |
| CVE-2017-8623 | Windows Hyper-V in Windows 10 1607, 1703, and Windows Server 2016 allows a denial of service vulnerability when it fails to properly validate input from a privileged user on a guest operating system, aka "Windows Hyper-V Denial of Service Vulnerability". |
| CVE-2017-3753 | A vulnerability has been identified in some Lenovo products that use UEFI (BIOS) code developed by American Megatrends, Inc. (AMI). With this vulnerability, conditions exist where an attacker with administrative privileges or physical access to a system may be able to run specially crafted code that can allow them to bypass system protections such as Device Guard and Hyper-V. |
| CVE-2017-0212 | Windows Hyper-V allows an elevation of privilege vulnerability when Microsoft Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 fail to properly validate vSMB packet data, aka "Windows Hyper-V vSMB Elevation of Privilege Vulnerability". |
| CVE-2017-0193 | Windows Hyper-V in Microsoft Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, Windows 10 Gold, 1511, 1607, 1703, and Windows Server 2016 allows an attacker to gain elevated privileges on a target guest operating system when Windows Hyper-V instruction emulation fails to properly enforce privilege levels, aka "Hypervisor Code Integrity Elevation of Privilege Vulnerability". |
| CVE-2017-0186 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch running on a Windows 10, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, or Windows Server 2016 host server fails to properly validate input from a privileged user on a guest operating system, aka "Hyper-V Denial of Service Vulnerability." This CVE ID is unique from CVE-2017-0178, CVE-2017-0179, CVE-2017-0182, CVE-2017-0183, CVE-2017-0184, and CVE-2017-0185. |
| CVE-2017-0185 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch running on a Windows 10, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, or Windows Server 2016 host server fails to properly validate input from a privileged user on a guest operating system, aka "Hyper-V Denial of Service Vulnerability." This CVE ID is unique from CVE-2017-0178, CVE-2017-0179, CVE-2017-0182, CVE-2017-0183, CVE-2017-0184, and CVE-2017-0186. |
| CVE-2017-0184 | A denial of service vulnerability exists when Microsoft Hyper-V running on a host server fails to properly validate input from a privileged user on a guest operating system, aka "Hyper-V Denial of Service Vulnerability." This CVE ID is unique from CVE-2017-0178, CVE-2017-0179, CVE-2017-0182, CVE-2017-0183, CVE-2017-0185, and CVE-2017-0186. |
| CVE-2017-0183 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch running on a Windows 10, Windows Server 2008 R2, Windows 8.1, Windows Server 2012 R2, or Windows Server 2016 host server fails to properly validate input from a privileged user on a guest operating system, aka "Hyper-V Denial of Service Vulnerability." This CVE ID is unique from CVE-2017-0178, CVE-2017-0179, CVE-2017-0182, CVE-2017-0184, CVE-2017-0185, and CVE-2017-0186. |
| CVE-2017-0182 | A denial of service vulnerability exists when Microsoft Hyper-V Network Switch running on a Windows 10, Windows Server 2008 R2, Windows 8.1, Windows Server 2012 R2, or Windows Server 2016 host server fails to properly validate input from a privileged user on a guest operating system, aka "Hyper-V Denial of Service Vulnerability." This CVE ID is unique from CVE-2017-0178, CVE-2017-0179, CVE-2017-0183, CVE-2017-0184, CVE-2017-0185, and CVE-2017-0186. |
| CVE-2017-0181 | A remote code execution vulnerability exists when Windows Hyper-V Network Switch running on a Windows 10 or Windows Server 2016 host server fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Remote Code Execution Vulnerability." This CVE ID is unique from CVE-2017-0162, CVE-2017-0163, and CVE-2017-0180. |
| CVE-2017-0180 | A remote code execution vulnerability exists when Windows Hyper-V Network Switch running on a host server fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Remote Code Execution Vulnerability." This CVE ID is unique from CVE-2017-0162, CVE-2017-0163, and CVE-2017-0181. |
| CVE-2017-0179 | A denial of service vulnerability exists when Microsoft Hyper-V running on a Windows 10, Windows 8.1, Windows Server 2012 R2, or Windows Server 2016 host server fails to properly validate input from a privileged user on a guest operating system, aka "Hyper-V Denial of Service Vulnerability." This CVE ID is unique from CVE-2017-0178, CVE-2017-0182, CVE-2017-0183, CVE-2017-0184, CVE-2017-0185, and CVE-2017-0186. |
| CVE-2017-0178 | A denial of service vulnerability exists when Microsoft Hyper-V running on Windows 10, Windows 10 1511, Windows 10 1607, Windows 8.1, Windows Server 2012 R2, and Windows Server 2016 host server fails to properly validate input from a privileged user on a guest operating system, aka "Hyper-V Denial of Service Vulnerability." This CVE ID is unique from CVE-2017-0179, CVE-2017-0182, CVE-2017-0183, CVE-2017-0184, CVE-2017-0185, and CVE-2017-0186. |
| CVE-2017-0169 | An information disclosure vulnerability exists when Windows Hyper-V running on a Windows 8.1, Windows Server 2012. or Windows Server 2012 R2 host operating system fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Information Disclosure Vulnerability." This CVE ID is unique from CVE-2017-0168. |
| CVE-2017-0168 | An information disclosure vulnerability exists when the Windows Hyper-V Network Switch running on a Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 host operating system fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Information Disclosure Vulnerability." This CVE ID is unique from CVE-2017-0169. |
| CVE-2017-0163 | A remote code execution vulnerability exists when Windows Hyper-V Network Switch running on a host server fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Remote Code Execution Vulnerability." This CVE ID is unique from CVE-2017-0162, CVE-2017-0180, and CVE-2017-0181. |
| CVE-2017-0162 | A remote code execution vulnerability exists when Windows Hyper-V Network Switch running on a Windows 10, Windows 8.1, Windows Server 2012 R2, or Windows Server 2016 host server fails to properly validate input from an authenticated user on a guest operating system, aka "Hyper-V Remote Code Execution Vulnerability." This CVE ID is unique from CVE-2017-0163, CVE-2017-0180, and CVE-2017-0181. |
| CVE-2017-0109 | Hyper-V in Microsoft Windows Vista SP2; Windows Server 2008 SP2 and R2; Windows 7 SP1; Windows 8.1; Windows Server 2012 Gold and R2; Windows 10 Gold, 1511, and 1607; and Windows Server 2016 allows guest OS users to execute arbitrary code on the host OS via a crafted application, aka "Hyper-V Remote Code Execution Vulnerability." This vulnerability is different from that described in CVE-2017-0075. |
| CVE-2017-0099 | Hyper-V in Microsoft Windows Vista SP2; Windows Server 2008 SP2 and 2008 R2; Windows 7 SP1; Windows 8.1; Windows Server 2012 Gold and R2; Windows 10 Gold, 1511, and 1607; and Windows Server 2016 allows guest OS users, running as virtual machines, to cause a denial of service via a crafted application, aka "Hyper-V Denial of Service Vulnerability." This vulnerability is different from those described in CVE-2017-0098, CVE-2017-0074, CVE-2017-0076, and CVE-2017-0097. |
| CVE-2017-0098 | Hyper-V in Microsoft Windows 10 Gold, 1511, and 1607; and Windows Server 2016 allows guest OS users, running as virtual machines, to cause a denial of service via a crafted application, aka "Hyper-V Denial of Service Vulnerability." This vulnerability is different from those described in CVE-2017-0074, CVE-2017-0076, CVE-2017-0097, and CVE-2017-0099. |
| CVE-2017-0097 | Hyper-V in Microsoft Windows Vista SP2; Windows Server 2008 SP2 and 2008 R2; Windows 7 SP1; Windows 8.1; Windows Server 2012 and R2; Windows 10, 1511, and 1607; and Windows Server 2016 allows guest OS users, running as virtual machines, to cause a denial of service via a crafted application, aka "Hyper-V Denial of Service Vulnerability." This vulnerability is different from those described in CVE-2017-0098, CVE-2017-0074, CVE-2017-0076, and CVE-2017-0099. |
| CVE-2017-0096 | Hyper-V in Microsoft Windows Vista SP2; Windows Server 2008 SP2 and R2; Windows 7 SP1; Windows 8.1, Windows Server 2012 Gold and R2; Windows 10 Gold, 1511, and 1607; and Windows Server 2016 allows guest OS users to obtain sensitive information from host OS memory via a crafted application, aka "Hyper-V Information Disclosure Vulnerability." |
| CVE-2017-0095 | Hyper-V in Microsoft Windows 10 Gold, 1511, and 1607 and Windows Server 2016 does not properly validate vSMB packet data, which allows attackers to execute arbitrary code on a target OS, aka "Hyper-V vSMB Remote Code Execution Vulnerability." This vulnerability is different from that described in CVE-2017-0021. |
| CVE-2017-0076 | Hyper-V in Microsoft Windows Vista SP2; Windows Server 2008 SP2 and 2008 R2; Windows 7 SP1; Windows 8.1; Windows Server 2012 and R2; Windows 10, 1511, and 1607; and Windows Server 2016 allows guest OS users, running as virtual machines, to cause a denial of service via a crafted application, aka "Hyper-V Denial of Service Vulnerability." This vulnerability is different from those described in CVE-2017-0098, CVE-2017-0074, CVE-2017-0097, and CVE-2017-0099. |
| CVE-2017-0075 | Hyper-V in Microsoft Windows Vista SP2; Windows Server 2008 SP2 and R2; Windows 7 SP1; Windows 8.1; Windows Server 2012 Gold and R2; Windows 10 Gold, 1511, and 1607; and Windows Server 2016 allows guest OS users to execute arbitrary code on the host OS via a crafted application, aka "Hyper-V Remote Code Execution Vulnerability." This vulnerability is different from that described in CVE-2017-0109. |
| CVE-2017-0074 | Hyper-V in Microsoft Windows Vista SP2; Windows Server 2008 SP2 and 2008 R2; Windows 7 SP1; Windows 8.1; Windows Server 2012 and R2; Windows 10, 1511, and 1607; and Windows Server 2016 allows guest OS users, running as virtual machines, to cause a denial of service via a crafted application, aka "Hyper-V Denial of Service Vulnerability." This vulnerability is different from those described in CVE-2017-0098, CVE-2017-0076, CVE-2017-0097, and CVE-2017-0099. |
| CVE-2017-0051 | Microsoft Windows 10 1607 and Windows Server 2016 allow remote attackers to cause a denial of service (application hang) via a crafted Office document, aka "Microsoft Hyper-V Network Switch Denial of Service Vulnerability." This vulnerability is different from those described in CVE-2017-0074, CVE-2017-0076, CVE-2017-0097, CVE-2017-0098, and CVE-2017-0099. |
| CVE-2017-0021 | Hyper-V in Microsoft Windows 10 1607 and Windows Server 2016 does not properly validate vSMB packet data, which allows attackers to execute arbitrary code on a target OS, aka "Hyper-V System Data Structure Vulnerability." This vulnerability is different from that described in CVE-2017-0095. |
| CVE-2016-4440 | arch/x86/kvm/vmx.c in the Linux kernel through 4.6.3 mishandles the APICv on/off state, which allows guest OS users to obtain direct APIC MSR access on the host OS, and consequently cause a denial of service (host OS crash) or possibly execute arbitrary code on the host OS, via x2APIC mode. |
| CVE-2016-0090 | Hyper-V in Microsoft Windows 8.1, Windows Server 2012 R2, and Windows 10 allows guest OS users to obtain sensitive information from host OS memory via a crafted application, aka "Hyper-V Information Disclosure Vulnerability." |
| CVE-2016-0089 | Hyper-V in Microsoft Windows 8.1, Windows Server 2012 Gold and R2, and Windows 10 allows guest OS users to obtain sensitive information from host OS memory via a crafted application, aka "Hyper-V Information Disclosure Vulnerability." |
| CVE-2016-0088 | Hyper-V in Microsoft Windows 8.1, Windows Server 2012 Gold and R2, and Windows 10 allows guest OS users to execute arbitrary code on the host OS via a crafted application, aka "Hyper-V Remote Code Execution Vulnerability." |
| CVE-2015-2534 | Hyper-V in Microsoft Windows 8.1, Windows Server 2012 R2, and Windows 10 improperly processes ACL settings, which allows local users to bypass intended network-traffic restrictions via a crafted application, aka "Hyper-V Security Feature Bypass Vulnerability." |
| CVE-2015-2362 | Hyper-V in Microsoft Windows Server 2008 SP2 and R2 SP1, Windows 8, Windows 8.1, and Windows Server 2012 Gold and R2 does not properly initialize guest OS system data structures, which allows guest OS users to execute arbitrary code on the host OS by leveraging guest OS privileges, aka "Hyper-V System Data Structure Vulnerability." |
| CVE-2015-2361 | Hyper-V in Microsoft Windows 8.1 and Windows Server 2012 R2 does not properly initialize guest OS system data structures, which allows guest OS users to execute arbitrary code on the host OS or cause a denial of service (buffer overflow) by leveraging guest OS privileges, aka "Hyper-V Buffer Overflow Vulnerability." |
| CVE-2015-1647 | Virtual Machine Manager (VMM) in Hyper-V in Microsoft Windows 8.1 and Windows Server 2012 R2 allows guest OS users to cause a denial of service (VMM functionality loss) via a crafted application, aka "Windows Hyper-V DoS Vulnerability." |
| CVE-2014-0148 | Qemu before 2.0 block driver for Hyper-V VHDX Images is vulnerable to infinite loops and other potential issues when calculating BAT entries, due to missing bounds checks for block_size and logical_sector_size variables. These are used to derive other fields like 'sectors_per_block' etc. A user able to alter the Qemu disk image could ise this flaw to crash the Qemu instance resulting in DoS. |
| CVE-2013-5556 | The license-installation module on the Cisco Nexus 1000V switch 4.2(1)SV1(5.2b) and earlier for VMware vSphere, Cisco Nexus 1000V switch 5.2(1)SM1(5.1) for Microsoft Hyper-V, and Cisco Virtual Security Gateway 4.2(1)VSG1(1) for Nexus 1000V switches allows local users to gain privileges and execute arbitrary commands via crafted "install all iso" arguments, aka Bug ID CSCui21340. |
| CVE-2013-3898 | Microsoft Windows 8 and Windows Server 2012, when Hyper-V is used, does not ensure memory-address validity, which allows guest OS users to execute arbitrary code in all guest OS instances, and allows guest OS users to cause a denial of service (host OS crash), via a guest-to-host hypercall with a crafted function parameter, aka "Address Corruption Vulnerability." |
| CVE-2012-5532 | The main function in tools/hv/hv_kvp_daemon.c in hypervkvpd, as distributed in the Linux kernel before 3.8-rc1, allows local users to cause a denial of service (daemon exit) via a crafted application that sends a Netlink message. NOTE: this vulnerability exists because of an incorrect fix for CVE-2012-2669. |
| CVE-2012-2669 | The main function in tools/hv/hv_kvp_daemon.c in hypervkvpd, as distributed in the Linux kernel before 3.4.5, does not validate the origin of Netlink messages, which allows local users to spoof Netlink communication via a crafted connector message. |
| CVE-2011-1872 | Hyper-V in Microsoft Windows Server 2008 Gold, SP2, R2, and R2 SP1 allows guest OS users to cause a denial of service (host OS infinite loop) via malformed machine instructions in a VMBus packet, aka "VMBus Persistent DoS Vulnerability." |
| CVE-2010-3960 | Hyper-V in Microsoft Windows Server 2008 Gold, SP2, and R2 allows guest OS users to cause a denial of service (host OS hang) by sending a crafted encapsulated packet over the VMBus, aka "Hyper-V VMBus Vulnerability." |
| CVE-2010-0026 | The Hyper-V server implementation in Microsoft Windows Server 2008 Gold, SP2, and R2 on the x64 platform allows guest OS users to cause a denial of service (host OS hang) via a crafted application that executes a malformed series of machine instructions, aka "Hyper-V Instruction Set Validation Vulnerability." |
|
You can also search by reference using the CVE Reference Maps.
For More Information: CVE Request Web Form (select “Other” from dropdown)
|
||
