On Wed, 9 Dec 2020 17:17:56 +0200 Paraschiv, Andra-Irina wrote:
Or use svm_zero as a gate for interpreting other fields?I agree that could be a problem, but here some considerations:Thanks for the follow-up info.
- I checked some applications (qemu-guest-agent, ncat, iperf-vsock) and
all use the same pattern: allocate memory, initialize all the
sockaddr_vm to zero (to be sure to initialize the svm_zero), set the
cid and port fields.
So we should be safe, but of course it may not always be true.
- For now the issue could affect only nested VMs. We introduced this
support one year ago, so it's something new and maybe we don't cause
too many problems.
As an alternative, what about using 1 or 2 bytes from svm_zero[]?
These must be set at zero, even if we only check the first byte in the
kernel.
We can also consider the "svm_zero" option and could use 2 bytes from
that field for "svm_flags", keeping the same "unsigned short" type.
If svm_zero[0]* == something start checking the value of reserved1?
* in practice the name can be unioned to something more palatable ;)