VSOCK: bind to random port for VMADDR_PORT_ANY
Subsystems (3)
PATCH 1/1 VSOCK: bind to random port for VMADDR_PORT_ANY
The old code always starts from fixed port for VMADDR_PORT_ANY. Sometimes when VMM crashed, there is still orphaned vsock which is waiting for close timer, then it could cause connection time out for new started VM if they are trying to connect to same port with same guest cid since the new packets could hit that orphaned vsock. We could also fix this by doing more in vhost_vsock_reset_orphans, but any way, it should be better to start from a random local port instead of a fixed one.
--- net/vmw_vsock/af_vsock.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
net/vmw_vsock/af_vsock.c +5 -1
@@ -107,6 +107,7 @@#include <linux/mutex.h> #include <linux/net.h> #include <linux/poll.h> +#include <linux/random.h> #include <linux/skbuff.h> #include <linux/smp.h> #include <linux/socket.h>
@@ -504,9 +505,12 @@ static void vsock_pending_work(struct work_struct *work)static int __vsock_bind_stream (struct vsock_sock *vsk,struct sockaddr_vm *addr) { -static u32 port =LAST_RESERVED_PORT +1 ; +static u32 port =0 ;struct sockaddr_vm new_addr; +if (!port) + port =prandom_u32 (); +vsock_addr_init (&new_addr, addr->svm_cid, addr->svm_port);if (addr->svm_port ==VMADDR_PORT_ANY ) {
Signature · 1 line
2.20.0.rc2.403.gdbc3b29805-goog
Greg KH
maintainerQuoted 8 lines · Lepton Wu
The old code always starts from fixed port for
VMADDR_PORT_ANY. Sometimes when VMM crashed, there is still orphaned vsock which is waiting for close timer, then it could cause connection time out for new started VM if they are trying to connect to same port with same guest cid since the new packets could hit that orphaned vsock. We could also fix this by doing more invhost_vsock_reset_orphans, but any way, it should be better to start from a random local port instead of a fixed one.
Quoted 4 lines
Signed-off-by Lepton Wu <[email protected]>--- net/vmw_vsock/af_vsock.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
<formletter>
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>