Dear all,
my fuzzing infrastructure discovered that an assert in
x86_emulate_wrapper is able to be triggered by an HVM domain executing a
specially crafted repeating movs instruction.
Specifically, if the emulation of the rep movs instruction triggers an
exception (e.g. by accessing invalid
On 4/25/25 11:11, Jan Beulich wrote:
On 24.04.2025 16:04, Andrew Cooper wrote:
I have a sneaking suspicion that this is sufficient:
diff --git a/xen/arch/x86/x86_emulate/private.h
b/xen/arch/x86/x86_emulate/private.h
index 30be59547032..9f3d6f0e5357 100644
--- a/xen/arch/x86/x86_emulate/private
On 4/16/25 15:52, Jan Beulich wrote:
On 15.04.2025 23:52, Manuel Andreas wrote:
my fuzzing infrastructure discovered that an assert in
x86_emulate_wrapper is able to be triggered by an HVM domain executing a
specially crafted repeating movs instruction.
Specifically, if the emulation of the
Dear all,
I've discovered an issue in the nested VMX implementation, where an
unprivileged domain is able to force Xen to dereference a NULL pointer,
resulting in a panic.
This is possible when:
1. The malicious domain has nested HVM capabilities.
2. The CPU is running on top of VMX and supp
On 6/2/25 4:12 PM, Jan Beulich wrote:
On 02.06.2025 15:39, Manuel Andreas wrote:
I've discovered an issue in the nested VMX implementation, where an
unprivileged domain is able to force Xen to dereference a NULL pointer,
resulting in a panic.
Sadly you provide no details on this NULL
On 6/2/25 17:42, Jan Beulich wrote:
This is possible when:
1. The malicious domain has nested HVM capabilities.
2. The CPU is running on top of VMX and supports shadow VMCS.
To trigger the bug, the domain must first enable VMX operation for
itself, execute VMXON and then finally execute
