linux-stable.git/net/vmw_vsock, branch v6.6.78

vsock: Allow retrying on connect() failure

2025-02-08T08:52:31+00:00

[ Upstream commit aa388c72113b7458127b709bdd7d3628af26e9b4 ]

sk_err is set when a (connectible) connect() fails. Effectively, this makes
an otherwise still healthy SS_UNCONNECTED socket impossible to use for any
subsequent connection attempts.

Clear sk_err upon trying to establish a connection.

Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Reviewed-by: Stefano Garzarella 
Reviewed-by: Luigi Leonardi 
Signed-off-by: Michal Luczaj 
Link: https://patch.msgid.link/20250128-vsock-transport-vs-autobind-v3-2-1cf57065b770@rbox.co
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

vsock: prevent null-ptr-deref in vsock_*[has_data|has_space]

2025-01-23T16:21:16+00:00

commit 91751e248256efc111e52e15115840c35d85abaf upstream.

Recent reports have shown how we sometimes call vsock_*_has_data()
when a vsock socket has been de-assigned from a transport (see attached
links), but we shouldn't.

Previous commits should have solved the real problems, but we may have
more in the future, so to avoid null-ptr-deref, we can return 0
(no space, no data available) but with a warning.

This way the code should continue to run in a nearly consistent state
and have a warning that allows us to debug future problems.

Fixes: c0cfa2d8a788 ("vsock: add multi-transports support")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/netdev/Z2K%2FI4nlHdfMRTZC@v4bel-B760M-AORUS-ELITE-AX/
Link: https://lore.kernel.org/netdev/5ca20d4c-1017-49c2-9516-f6f75fd331e9@rbox.co/
Link: https://lore.kernel.org/netdev/677f84a8.050a0220.25a300.01b3.GAE@google.com/
Co-developed-by: Hyunwoo Kim 
Signed-off-by: Hyunwoo Kim 
Co-developed-by: Wongi Lee 
Signed-off-by: Wongi Lee 
Signed-off-by: Stefano Garzarella 
Reviewed-by: Luigi Leonardi 
Reviewed-by: Hyunwoo Kim 
Signed-off-by: Paolo Abeni 
Signed-off-by: Greg Kroah-Hartman

vsock: reset socket state when de-assigning the transport

2025-01-23T16:21:16+00:00

commit a24009bc9be60242651a21702609381b5092459e upstream.

Transport's release() and destruct() are called when de-assigning the
vsock transport. These callbacks can touch some socket state like
sock flags, sk_state, and peer_shutdown.

Since we are reassigning the socket to a new transport during
vsock_connect(), let's reset these fields to have a clean state with
the new transport.

Fixes: c0cfa2d8a788 ("vsock: add multi-transports support")
Cc: stable@vger.kernel.org
Signed-off-by: Stefano Garzarella 
Reviewed-by: Luigi Leonardi 
Signed-off-by: Paolo Abeni 
Signed-off-by: Greg Kroah-Hartman

vsock/virtio: cancel close work in the destructor

2025-01-23T16:21:16+00:00

commit df137da9d6d166e87e40980e36eb8e0bc90483ef upstream.

During virtio_transport_release() we can schedule a delayed work to
perform the closing of the socket before destruction.

The destructor is called either when the socket is really destroyed
(reference counter to zero), or it can also be called when we are
de-assigning the transport.

In the former case, we are sure the delayed work has completed, because
it holds a reference until it completes, so the destructor will
definitely be called after the delayed work is finished.
But in the latter case, the destructor is called by AF_VSOCK core, just
after the release(), so there may still be delayed work scheduled.

Refactor the code, moving the code to delete the close work already in
the do_close() to a new function. Invoke it during destruction to make
sure we don't leave any pending work.

Fixes: c0cfa2d8a788 ("vsock: add multi-transports support")
Cc: stable@vger.kernel.org
Reported-by: Hyunwoo Kim 
Closes: https://lore.kernel.org/netdev/Z37Sh+utS+iV3+eb@v4bel-B760M-AORUS-ELITE-AX/
Signed-off-by: Stefano Garzarella 
Reviewed-by: Luigi Leonardi 
Tested-by: Hyunwoo Kim 
Signed-off-by: Paolo Abeni 
Signed-off-by: Greg Kroah-Hartman

vsock/virtio: discard packets if the transport changes

2025-01-23T16:21:16+00:00

commit 2cb7c756f605ec02ffe562fb26828e4bcc5fdfc1 upstream.

If the socket has been de-assigned or assigned to another transport,
we must discard any packets received because they are not expected
and would cause issues when we access vsk->transport.

A possible scenario is described by Hyunwoo Kim in the attached link,
where after a first connect() interrupted by a signal, and a second
connect() failed, we can find `vsk->transport` at NULL, leading to a
NULL pointer dereference.

Fixes: c0cfa2d8a788 ("vsock: add multi-transports support")
Cc: stable@vger.kernel.org
Reported-by: Hyunwoo Kim 
Reported-by: Wongi Lee 
Closes: https://lore.kernel.org/netdev/Z2LvdTTQR7dBmPb5@v4bel-B760M-AORUS-ELITE-AX/
Signed-off-by: Stefano Garzarella 
Reviewed-by: Hyunwoo Kim 
Signed-off-by: Paolo Abeni 
Signed-off-by: Greg Kroah-Hartman

vsock/bpf: return early if transport is not assigned

2025-01-23T16:21:15+00:00

commit f6abafcd32f9cfc4b1a2f820ecea70773e26d423 upstream.

Some of the core functions can only be called if the transport
has been assigned.

As Michal reported, a socket might have the transport at NULL,
for example after a failed connect(), causing the following trace:

    BUG: kernel NULL pointer dereference, address: 00000000000000a0
    #PF: supervisor read access in kernel mode
    #PF: error_code(0x0000) - not-present page
    PGD 12faf8067 P4D 12faf8067 PUD 113670067 PMD 0
    Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 15 UID: 0 PID: 1198 Comm: a.out Not tainted 6.13.0-rc2+
    RIP: 0010:vsock_connectible_has_data+0x1f/0x40
    Call Trace:
     vsock_bpf_recvmsg+0xca/0x5e0
     sock_recvmsg+0xb9/0xc0
     __sys_recvfrom+0xb3/0x130
     __x64_sys_recvfrom+0x20/0x30
     do_syscall_64+0x93/0x180
     entry_SYSCALL_64_after_hwframe+0x76/0x7e

So we need to check the `vsk->transport` in vsock_bpf_recvmsg(),
especially for connected sockets (stream/seqpacket) as we already
do in __vsock_connectible_recvmsg().

Fixes: 634f1a7110b4 ("vsock: support sockmap")
Cc: stable@vger.kernel.org
Reported-by: Michal Luczaj 
Closes: https://lore.kernel.org/netdev/5ca20d4c-1017-49c2-9516-f6f75fd331e9@rbox.co/
Tested-by: Michal Luczaj 
Reported-by: syzbot+3affdbfc986ecd9200fd@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/677f84a8.050a0220.25a300.01b3.GAE@google.com/
Tested-by: syzbot+3affdbfc986ecd9200fd@syzkaller.appspotmail.com
Reviewed-by: Hyunwoo Kim 
Acked-by: Michael S. Tsirkin 
Reviewed-by: Luigi Leonardi 
Signed-off-by: Stefano Garzarella 
Signed-off-by: Paolo Abeni 
Signed-off-by: Greg Kroah-Hartman

bpf, vsock: Invoke proto::close on close()

2024-12-14T18:59:47+00:00

[ Upstream commit 135ffc7becc82cfb84936ae133da7969220b43b2 ]

vsock defines a BPF callback to be invoked when close() is called. However,
this callback is never actually executed. As a result, a closed vsock
socket is not automatically removed from the sockmap/sockhash.

Introduce a dummy vsock_close() and make vsock_release() call proto::close.

Note: changes in __vsock_release() look messy, but it's only due to indent
level reduction and variables xmas tree reorder.

Fixes: 634f1a7110b4 ("vsock: support sockmap")
Signed-off-by: Michal Luczaj 
Reviewed-by: Stefano Garzarella 
Reviewed-by: Luigi Leonardi 
Link: https://lore.kernel.org/r/20241118-vsock-bpf-poll-close-v1-3-f1b9669cacdc@rbox.co
Signed-off-by: Alexei Starovoitov 
Acked-by: John Fastabend 
Signed-off-by: Sasha Levin

bpf, vsock: Fix poll() missing a queue

2024-12-14T18:59:47+00:00

[ Upstream commit 9f0fc98145218ff8f50d8cfa3b393785056c53e1 ]

When a verdict program simply passes a packet without redirection, sk_msg
is enqueued on sk_psock::ingress_msg. Add a missing check to poll().

Fixes: 634f1a7110b4 ("vsock: support sockmap")
Signed-off-by: Michal Luczaj 
Reviewed-by: Stefano Garzarella 
Reviewed-by: Luigi Leonardi 
Link: https://lore.kernel.org/r/20241118-vsock-bpf-poll-close-v1-1-f1b9669cacdc@rbox.co
Signed-off-by: Alexei Starovoitov 
Acked-by: John Fastabend 
Signed-off-by: Sasha Levin

sock_diag: add module pointer to "struct sock_diag_handler"

2024-12-09T09:32:09+00:00

[ Upstream commit 114b4bb1cc19239b272d52ebbe156053483fe2f8 ]

Following patch is going to use RCU instead of
sock_diag_table_mutex acquisition.

This patch is a preparation, no change of behavior yet.

Signed-off-by: Eric Dumazet 
Reviewed-by: Guillaume Nault 
Reviewed-by: Kuniyuki Iwashima 
Reviewed-by: Willem de Bruijn 
Signed-off-by: Paolo Abeni 
Stable-dep-of: eb02688c5c45 ("ipv6: release nexthop on device removal")
Signed-off-by: Sasha Levin

virtio/vsock: Fix accept_queue memory leak

2024-11-22T14:38:32+00:00

[ Upstream commit d7b0ff5a866724c3ad21f2628c22a63336deec3f ]

As the final stages of socket destruction may be delayed, it is possible
that virtio_transport_recv_listen() will be called after the accept_queue
has been flushed, but before the SOCK_DONE flag has been set. As a result,
sockets enqueued after the flush would remain unremoved, leading to a
memory leak.

vsock_release
  __vsock_release
    lock
    virtio_transport_release
      virtio_transport_close
        schedule_delayed_work(close_work)
    sk_shutdown = SHUTDOWN_MASK
(!) flush accept_queue
    release
                                        virtio_transport_recv_pkt
                                          vsock_find_bound_socket
                                          lock
                                          if flag(SOCK_DONE) return
                                          virtio_transport_recv_listen
                                            child = vsock_create_connected
                                      (!)   vsock_enqueue_accept(child)
                                          release
close_work
  lock
  virtio_transport_do_close
    set_flag(SOCK_DONE)
    virtio_transport_remove_sock
      vsock_remove_sock
        vsock_remove_bound
  release

Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during
socket destruction.

unreferenced object 0xffff888109e3f800 (size 2040):
  comm "kworker/5:2", pid 371, jiffies 4294940105
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00  (..@............
  backtrace (crc 9e5f4e84):
    [] kmem_cache_alloc_noprof+0x2c1/0x360
    [] sk_prot_alloc+0x30/0x120
    [] sk_alloc+0x2c/0x4b0
    [] __vsock_create.constprop.0+0x2a/0x310
    [] virtio_transport_recv_pkt+0x4dc/0x9a0
    [] vsock_loopback_work+0xfd/0x140
    [] process_one_work+0x20c/0x570
    [] worker_thread+0x1bf/0x3a0
    [] kthread+0xdd/0x110
    [] ret_from_fork+0x2d/0x50
    [] ret_from_fork_asm+0x1a/0x30

Fixes: 3fe356d58efa ("vsock/virtio: discard packets only when socket is really closed")
Reviewed-by: Stefano Garzarella 
Signed-off-by: Michal Luczaj 
Signed-off-by: Paolo Abeni 
Signed-off-by: Sasha Levin