You mean the checksum bit right. Letting a corrupted packet pass through? Funny that it was a corrupted length value that caused the problem which I seem to recall one of the big attack vector when its intentional.

I'd say the "trusting the length value from the client and using it to allocate memory" is the one issue that actually has security implications.

The checksum thing is not a vulnerability. If you can't trust the remote host to put the correct things in a packet, a checksum will not help you.

I was wondering for a moment if any MITM was possible at some steps. But it also happens for encrypted packet right and maybe MITM is not possible in that case. I don't really know the steps involved in creating, encrypting packets to judge the possibility.

Xen failing to save/restore registers across VMs almost certainly has security implications.

That is a really really bad thing ins't it, completely giving away the isolation at the very lowest level?

How come this happens though. Saving/restoring the full set of registers is easy right, everyone knows the full list. Do they try limit the set of register to save/restore depending on the operation to improve performance thus causing the bug? It seems like it should be one of the most validated piece of a hypervisor code given that isolation is one of biggest selling point specially now with containers doing the resource sharing bit more efficiently it seems.