On Wed, 9 Dec 2020 17:17:56 +0200 Paraschiv, Andra-Irina wrote:

quoted

I agree that could be a problem, but here some considerations:
- 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.  

Thanks for the follow-up info.

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.

Or use svm_zero as a gate for interpreting other fields?
If svm_zero[0]* == something start checking the value of reserved1?
* in practice the name can be unioned to something more palatable ;)