fix: prevent integer overflow in 32-bit binaries when configuring virtual disk #2200
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Virtual disk sizes are passed to the API in bytes during VM reconfiguration. This means that sizes in excess of 2GB will overflow a signed 32-bit integer.
In golang the default int type's size is dependent on the OS. This means that trying to add a virtual disk larger than 2GB while cloning a VM and running a 32-bit version of the provider will cause an overflow.
The bindings that we use to call the API use int64 which means that the problem is in the provider and not in
govmomi
.The actual conversion looks like this:
disk.CapacityInBytes = structure.GiBToByte(ns.(int))
The bug is caused by
GiBToByte
which overflows internally and hides the problem.We end up in the 1st case. The integer cast in the brackets is effectively a int32 cast since we run on a 32bit OS.
This causes the overflow.
To fix this I am modifying the call to
GiBToByte
by passing the parameter as int64 which forces the function to go through the 64bit case.Acceptance tests
Ran
TestAccResourceVSphereVirtualMachine_cloneFromTemplate
andTestAccResourceVSphereVirtualMachine_basic
just to make sure there are no obvious regressionsRelease Note
Release note for CHANGELOG:
References
Closes #2116
CLoses #1578