VMware Server

What's new in this version:

Issues Resolved in VMware Server 1.0.3
- This release fixes a problem with VMware Tools that caused the guest to run out of memory.
- VMware Server 1.0.3 fixes a bug introduced in the VMware Server version 1.0.2 VIX API. As a result of this bug, if Vix_ReleaseHandle (vmhandle) and VixHost_Disconnect (hosthandle) are called, a crash occurs in VixHost_Disconnect(). This crash is accompanied by the following error message:

VMware Server Error:
VMware Server unrecoverable error: (app)
ASSERT /build/mts/release/bora-39867/pompeii2005/bora/lib/vmdb/vmdbCtx.c:487 bugNr=23952
A log file is available in "/tmp/vmware-mark/vix-3749.log". Please request support and include the contents of the log file.
To collect files to submit to VMware support, run vm-support.
We will respond on the basis of your support entitlement.


Security Issues Resolved in VMware Server 1.0.3
- Virtual machines can be put in various states of suspension, as specified by the ACPI power management standard. When returning from a sleep state (S2) to the run state (S0), the virtual machine process (VMX) collects information about the last recorded running state for the virtual machine. Under some circumstances, VMX read state information from an incorrect memory location. This issue could be used to complete a successful Denial-of-Service attack where the virtual machine would need to be rebooted.
- Some VMware products support storing configuration information in VMware system files. Under some circumstances, a malicious user could instruct the virtual machine process (VMX) to store malformed data, causing an error. This error could enable a successful Denial-of-Service attack on guest operating systems.
- Some VMware products managed memory in a way that failed to gracefully handle some general protection faults (GPFs) in Windows guest operating systems. A malicious user could use this vulnerability to crash Windows virtual machines. While this vulnerability could allow an attacker to crash a virtual machine, we do not believe it was possible to escalate privileges or escape virtual containment.
- In a 64-bit Windows guest on a 64-bit host, debugging local programs could create system instability. Using a debugger to step into a syscall instruction may corrupt the virtual machine's register context. This corruption produces unpredictable results including corrupted stack pointers, kernel bugchecks, or vmware-vmx process failures.