linux-stable.git/net/vmw_vsock, branch v5.4.271

virtio/vsock: fix logic which reduces credit update messages

2024-01-25T22:34:25+00:00

[ Upstream commit 93b80887668226180ea5f5349cc728ca6dc700ab ]

Add one more condition for sending credit update during dequeue from
stream socket: when number of bytes in the rx queue is smaller than
SO_RCVLOWAT value of the socket. This is actual for non-default value
of SO_RCVLOWAT (e.g. not 1) - idea is to "kick" peer to continue data
transmission, because we need at least SO_RCVLOWAT bytes in our rx
queue to wake up user for reading data (in corner case it is also
possible to stuck both tx and rx sides, this is why 'Fixes' is used).

Fixes: b89d882dc9fc ("vsock/virtio: reduce credit update messages")
Signed-off-by: Arseniy Krasnov 
Reviewed-by: Stefano Garzarella 
Acked-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

vsock/virtio: Fix unsigned integer wrap around in virtio_transport_has_space()

2023-12-20T14:41:17+00:00

[ Upstream commit 60316d7f10b17a7ebb1ead0642fee8710e1560e0 ]

We need to do signed arithmetic if we expect condition
`if (bytes < 0)` to be possible

Found by Linux Verification Center (linuxtesting.org) with SVACE

Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko")
Signed-off-by: Nikolay Kuratov 
Reviewed-by: Stefano Garzarella 
Link: https://lore.kernel.org/r/20231211162317.4116625-1-kniv@yandex-team.ru
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

vsock: avoid to close connected socket after the timeout

2023-05-30T11:44:05+00:00

[ Upstream commit 6d4486efe9c69626cab423456169e250a5cd3af5 ]

When client and server establish a connection through vsock,
the client send a request to the server to initiate the connection,
then start a timer to wait for the server's response. When the server's
RESPONSE message arrives, the timer also times out and exits. The
server's RESPONSE message is processed first, and the connection is
established. However, the client's timer also times out, the original
processing logic of the client is to directly set the state of this vsock
to CLOSE and return ETIMEDOUT. It will not notify the server when the port
is released, causing the server port remain.
when client's vsock_connect timeout，it should check sk state is
ESTABLISHED or not. if sk state is ESTABLISHED, it means the connection
is established, the client should not set the sk state to CLOSE

Note: I encountered this issue on kernel-4.18, which can be fixed by
this patch. Then I checked the latest code in the community
and found similar issue.

Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Signed-off-by: Zhuang Shengen 
Reviewed-by: Stefano Garzarella 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: vmw_vsock: vmci: Check memcpy_from_msg()

2023-01-18T10:41:13+00:00

[ Upstream commit 44aa5a6dba8283bfda28b1517af4de711c5652a4 ]

vmci_transport_dgram_enqueue() does not check the return value
of memcpy_from_msg().  If memcpy_from_msg() fails, it is possible that
uninitialized memory contents are sent unintentionally instead of user's
message in the datagram to the destination.  Return with an error if
memcpy_from_msg() fails.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: 0f7db23a07af ("vmci_transport: switch ->enqeue_dgram, ->enqueue_stream and ->dequeue_stream to msghdr")
Signed-off-by: Artem Chernyshev 
Reviewed-by: Stefano Garzarella 
Reviewed-by: Vishnu Dasa 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

vhost/vsock: Use kvmalloc/kvfree for larger packets.

2022-10-26T11:22:25+00:00

[ Upstream commit 0e3f72931fc47bb81686020cc643cde5d9cd0bb8 ]

When copying a large file over sftp over vsock, data size is usually 32kB,
and kmalloc seems to fail to try to allocate 32 32kB regions.

 vhost-5837: page allocation failure: order:4, mode:0x24040c0
 Call Trace:
  [] dump_stack+0x97/0xdb
  [] warn_alloc_failed+0x10f/0x138
  [] ? __alloc_pages_direct_compact+0x38/0xc8
  [] __alloc_pages_nodemask+0x84c/0x90d
  [] alloc_kmem_pages+0x17/0x19
  [] kmalloc_order_trace+0x2b/0xdb
  [] __kmalloc+0x177/0x1f7
  [] ? copy_from_iter+0x8d/0x31d
  [] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock]
  [] vhost_worker+0xf7/0x157 [vhost]
  [] kthread+0xfd/0x105
  [] ? vhost_dev_set_owner+0x22e/0x22e [vhost]
  [] ? flush_kthread_worker+0xf3/0xf3
  [] ret_from_fork+0x4e/0x80
  [] ? flush_kthread_worker+0xf3/0xf3

Work around by doing kvmalloc instead.

Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko")
Signed-off-by: Junichi Uekawa 
Reviewed-by: Stefano Garzarella 
Acked-by: Michael S. Tsirkin 
Link: https://lore.kernel.org/r/20220928064538.667678-1-uekawa@chromium.org
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

vsock: Set socket state back to SS_UNCONNECTED in vsock_connect_timeout()

2022-08-25T09:18:25+00:00

commit a3e7b29e30854ed67be0d17687e744ad0c769c4b upstream.

Imagine two non-blocking vsock_connect() requests on the same socket.
The first request schedules @connect_work, and after it times out,
vsock_connect_timeout() sets *sock* state back to TCP_CLOSE, but keeps
*socket* state as SS_CONNECTING.

Later, the second request returns -EALREADY, meaning the socket "already
has a pending connection in progress", even though the first request has
already timed out.

As suggested by Stefano, fix it by setting *socket* state back to
SS_UNCONNECTED, so that the second request will return -ETIMEDOUT.

Suggested-by: Stefano Garzarella 
Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Reviewed-by: Stefano Garzarella 
Signed-off-by: Peilin Ye 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

vsock: Fix memory leak in vsock_connect()

2022-08-25T09:18:25+00:00

commit 7e97cfed9929eaabc41829c395eb0d1350fccb9d upstream.

An O_NONBLOCK vsock_connect() request may try to reschedule
@connect_work.  Imagine the following sequence of vsock_connect()
requests:

  1. The 1st, non-blocking request schedules @connect_work, which will
     expire after 200 jiffies.  Socket state is now SS_CONNECTING;

  2. Later, the 2nd, blocking request gets interrupted by a signal after
     a few jiffies while waiting for the connection to be established.
     Socket state is back to SS_UNCONNECTED, but @connect_work is still
     pending, and will expire after 100 jiffies.

  3. Now, the 3rd, non-blocking request tries to schedule @connect_work
     again.  Since @connect_work is already scheduled,
     schedule_delayed_work() silently returns.  sock_hold() is called
     twice, but sock_put() will only be called once in
     vsock_connect_timeout(), causing a memory leak reported by syzbot:

  BUG: memory leak
  unreferenced object 0xffff88810ea56a40 (size 1232):
    comm "syz-executor756", pid 3604, jiffies 4294947681 (age 12.350s)
    hex dump (first 32 bytes):
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      28 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  (..@............
    backtrace:
      [] sk_prot_alloc+0x3e/0x1b0 net/core/sock.c:1930
      [] sk_alloc+0x32/0x2e0 net/core/sock.c:1989
      [] __vsock_create.constprop.0+0x38/0x320 net/vmw_vsock/af_vsock.c:734
      [] vsock_create+0xc1/0x2d0 net/vmw_vsock/af_vsock.c:2203
      [] __sock_create+0x1ab/0x2b0 net/socket.c:1468
      [] sock_create net/socket.c:1519 [inline]
      [] __sys_socket+0x6f/0x140 net/socket.c:1561
      [] __do_sys_socket net/socket.c:1570 [inline]
      [] __se_sys_socket net/socket.c:1568 [inline]
      [] __x64_sys_socket+0x1a/0x20 net/socket.c:1568
      [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      [] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:80
      [] entry_SYSCALL_64_after_hwframe+0x44/0xae
  <...>

Use mod_delayed_work() instead: if @connect_work is already scheduled,
reschedule it, and undo sock_hold() to keep the reference count
balanced.

Reported-and-tested-by: syzbot+b03f55bf128f9a38f064@syzkaller.appspotmail.com
Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Co-developed-by: Stefano Garzarella 
Signed-off-by: Stefano Garzarella 
Reviewed-by: Stefano Garzarella 
Signed-off-by: Peilin Ye 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

vsock: remove vsock from connected table when connect is interrupted by a signal

2022-02-23T10:59:57+00:00

commit b9208492fcaecff8f43915529ae34b3bcb03877c upstream.

vsock_connect() expects that the socket could already be in the
TCP_ESTABLISHED state when the connecting task wakes up with a signal
pending. If this happens the socket will be in the connected table, and
it is not removed when the socket state is reset. In this situation it's
common for the process to retry connect(), and if the connection is
successful the socket will be added to the connected table a second
time, corrupting the list.

Prevent this by calling vsock_remove_connected() if a signal is received
while waiting for a connection. This is harmless if the socket is not in
the connected table, and if it is in the table then removing it will
prevent list corruption from a double add.

Note for backporting: this patch requires d5afa82c977e ("vsock: correct
removal of socket from the list"), which is in all current stable trees
except 4.9.y.

Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Signed-off-by: Seth Forshee 
Reviewed-by: Stefano Garzarella 
Link: https://lore.kernel.org/r/20220217141312.2297547-1-sforshee@digitalocean.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

vsock: prevent unnecessary refcnt inc for nonblocking connect

2021-11-17T08:48:48+00:00

[ Upstream commit c7cd82b90599fa10915f41e3dd9098a77d0aa7b6 ]

Currently vosck_connect() increments sock refcount for nonblocking
socket each time it's called, which can lead to memory leak if
it's called multiple times because connect timeout function decrements
sock refcount only once.

Fixes it by making vsock_connect() return -EALREADY immediately when
sock state is already SS_CONNECTING.

Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Reviewed-by: Stefano Garzarella 
Signed-off-by: Eiichi Tsukata 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

vsock/virtio: avoid potential deadlock when vsock device remove

2021-08-18T06:57:01+00:00

[ Upstream commit 49b0b6ffe20c5344f4173f3436298782a08da4f2 ]

There's a potential deadlock case when remove the vsock device or
process the RESET event:

  vsock_for_each_connected_socket:
      spin_lock_bh(&vsock_table_lock) ----------- (1)
      ...
          virtio_vsock_reset_sock:
              lock_sock(sk) --------------------- (2)
      ...
      spin_unlock_bh(&vsock_table_lock)

lock_sock() may do initiative schedule when the 'sk' is owned by
other thread at the same time, we would receivce a warning message
that "scheduling while atomic".

Even worse, if the next task (selected by the scheduler) try to
release a 'sk', it need to request vsock_table_lock and the deadlock
occur, cause the system into softlockup state.
  Call trace:
   queued_spin_lock_slowpath
   vsock_remove_bound
   vsock_remove_sock
   virtio_transport_release
   __vsock_release
   vsock_release
   __sock_release
   sock_close
   __fput
   ____fput

So we should not require sk_lock in this case, just like the behavior
in vhost_vsock or vmci.

Fixes: 0ea9e1d3a9e3 ("VSOCK: Introduce virtio_transport.ko")
Cc: Stefan Hajnoczi 
Signed-off-by: Longpeng(Mike) 
Reviewed-by: Stefano Garzarella 
Link: https://lore.kernel.org/r/20210812053056.1699-1-longpeng2@huawei.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin