Use of the advisory constitutes acceptance for use in an "as is" condition. For all other reproduction or publication, in printing or otherwise, contact for permission. Unaltered electronic reproduction of this advisory is permitted. The application contains 3 actionButtons.
#Disable vstack driver#
#include Īs soon as the driver gets loaded it should crash the host hypervisor in the following way: Microsoft Hypervisor Kernel Version 18362 MP (2 procs) Free 圆4īuilt by: 18362.0.GitEnlistment(winpbld).191019-2253 Im having trouble disabling and enabling actionButton in Shiny Modules.I created a simple app to visualize my problem. The driver must be either signed, or signing enforcement (and SecureBoot) disabled in the VM.
#Disable vstack code#
The code must be compiled as a Windows Kernel Driver and get loaded in a guest VM running under Hyper-V. The cause of the bug is probably a typo calling a function with similar name to the caller (it is common in Microsoft to have many similar named functions with variations in the function prefix or suffix).īelow we provide the PoC code that triggers the bug condition. There doesn't seem to be any logical reason for the recursive call, moreover that kind of pattern is avoided in constrained stack space situations like hypervisor or kernel code. If the MSR index (a2) is in the 0xC0002000-0xC000200D range the function will call itself with the same unchanged arguments. The affected code is the following: _int64 _fastcall sub_FFFFF80000260EE0(_QWORD *a1, _int64 a2, _int64 a3) When handling guest VM writes to some MCA-related MSRs (for example MCA_DESTAT 0xC0002008) the execution path leads to an infinite recursive call. The hypervisor handles such an event and different actions are taken depending on the MSR indexed by RCX, which can include the emulation of real CPU MSRs or synthetic ones implementing hypervisor specific functionality. A 'wrmsr' instruction executed within a Hyper-V guest VM causes a vm-exit condition with exit code 32 (VMX_VMEXIT_WRMSR).
0 kommentar(er)
