kernel/linux.git/tools/testing/vsock/vsock_test.c, branch v6.18.22

vsock/test: fix seqpacket message bounds test

2026-01-30T09:32:21+00:00

[ Upstream commit 0a98de80136968bab7db37b16282b37f044694d3 ] The test requires the sender (client) to send all messages before waking up the receiver (server). Since virtio-vsock had a bug and did not respect the size of the TX buffer, this test worked, but now that we are going to fix the bug, the test hangs because the sender would fill the TX buffer before waking up the receiver. Set the buffer size in the sender (client) as well, as we already do for the receiver (server). Fixes: 5c338112e48a ("test/vsock: rework message bounds test") Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20260121093628.9941-3-sgarzare@redhat.com Acked-by: Michael S. Tsirkin Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

vsock/test: fix test for null ptr deref when transport changes

2025-07-10T02:33:07+00:00

In test_stream_transport_change_client(), the client sends CONTROL_CONTINUE on each iteration, even when connect() is unsuccessful. This causes a flood of control messages in the server that hangs around for more than 10 seconds after the test finishes, triggering several timeouts and causing subsequent tests to fail. This was discovered in testing a newly proposed test that failed in this way on the client side: ... 33 - SOCK_STREAM transport change null-ptr-deref...ok 34 - SOCK_STREAM ioctl(SIOCINQ) functionality...recv timed out The CONTROL_CONTINUE message is used only to tell to the server to call accept() to consume successful connections, so that subsequent connect() will not fail for finding the queue full. Send CONTROL_CONTINUE message only when the connect() has succeeded, or found the queue full. Note that the second connect() can also succeed if the first one was interrupted after sending the request. Fixes: 3a764d93385c ("vsock/test: Add test for null ptr deref when transport changes") Cc: leonardi@redhat.com Signed-off-by: Stefano Garzarella Reviewed-by: Luigi Leonardi Link: https://patch.msgid.link/20250708111701.129585-1-sgarzare@redhat.com Signed-off-by: Jakub Kicinski

test/vsock: Add ioctl SIOCINQ tests

2025-07-10T02:29:52+00:00

Add SIOCINQ ioctl tests for both SOCK_STREAM and SOCK_SEQPACKET. The client waits for the server to send data, and checks if the SIOCINQ ioctl value matches the data size. After consuming the data, the client checks if the SIOCINQ value is 0. Signed-off-by: Xuewei Niu Reviewed-by: Stefano Garzarella Tested-by: Luigi Leonardi Reviewed-by: Luigi Leonardi Link: https://patch.msgid.link/20250708-siocinq-v6-4-3775f9a9e359@antgroup.com Signed-off-by: Jakub Kicinski

vsock/test: Add test for null ptr deref when transport changes

2025-07-02T22:05:23+00:00

Add a new test to ensure that when the transport changes a null pointer dereference does not occur. The bug was reported upstream [1] and fixed with commit 2cb7c756f605 ("vsock/virtio: discard packets if the transport changes"). KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067] CPU: 2 UID: 0 PID: 463 Comm: kworker/2:3 Not tainted Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:vsock_stream_has_data+0x44/0x70 Call Trace: virtio_transport_do_close+0x68/0x1a0 virtio_transport_recv_pkt+0x1045/0x2ae4 vsock_loopback_work+0x27d/0x3f0 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x35a/0x700 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 Note that this test may not fail in a kernel without the fix, but it may hang on the client side if it triggers a kernel oops. This works by creating a socket, trying to connect to a server, and then executing a second connect operation on the same socket but to a different CID (0). This triggers a transport change. If the connect operation is interrupted by a signal, this could cause a null-ptr-deref. Since this bug is non-deterministic, we need to try several times. It is reasonable to assume that the bug will show up within the timeout period. If there is a G2H transport loaded in the system, the bug is not triggered and this test will always pass. This is because `vsock_assign_transport`, when using CID 0, like in this case, sets vsk->transport to `transport_g2h` that is not NULL if a G2H transport is available. [1]https://lore.kernel.org/netdev/Z2LvdTTQR7dBmPb5@v4bel-B760M-AORUS-ELITE-AX/ Suggested-by: Hyunwoo Kim Suggested-by: Michal Luczaj Signed-off-by: Luigi Leonardi Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20250630-test_vsock-v5-2-2492e141e80b@redhat.com Signed-off-by: Jakub Kicinski

vsock/test: Cover more CIDs in transport_uaf test

2025-06-17T21:50:27+00:00

Increase the coverage of test for UAF due to socket unbinding, and losing transport in general. It's a follow up to commit 301a62dfb0d0 ("vsock/test: Add test for UAF due to socket unbinding") and discussion in [1]. The idea remains the same: take an unconnected stream socket with a transport assigned and then attempt to switch the transport by trying (and failing) to connect to some other CID. Now do this iterating over all the well known CIDs (plus one). While at it, drop the redundant synchronization between client and server. Some single-transport setups can't be tested effectively; a warning is issued. Depending on transports available, a variety of splats are possible on unpatched machines. After reverting commit 78dafe1cf3af ("vsock: Orphan socket after transport release") and commit fcdd2242c023 ("vsock: Keep the binding until socket destruction"): BUG: KASAN: slab-use-after-free in __vsock_bind+0x61f/0x720 Read of size 4 at addr ffff88811ff46b54 by task vsock_test/1475 Call Trace: dump_stack_lvl+0x68/0x90 print_report+0x170/0x53d kasan_report+0xc2/0x180 __vsock_bind+0x61f/0x720 vsock_connect+0x727/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 WARNING: CPU: 0 PID: 1475 at net/vmw_vsock/virtio_transport_common.c:37 virtio_transport_send_pkt_info+0xb2b/0x1160 Call Trace: virtio_transport_connect+0x90/0xb0 vsock_connect+0x782/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:sock_has_perm+0xa7/0x2a0 Call Trace: selinux_socket_connect_helper.isra.0+0xbc/0x450 selinux_socket_connect+0x3b/0x70 security_socket_connect+0x31/0xd0 __sys_connect_file+0x79/0x1f0 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 1518 at lib/refcount.c:25 refcount_warn_saturate+0xdd/0x140 RIP: 0010:refcount_warn_saturate+0xdd/0x140 Call Trace: __vsock_bind+0x65e/0x720 vsock_connect+0x727/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 1475 at lib/refcount.c:28 refcount_warn_saturate+0x12b/0x140 RIP: 0010:refcount_warn_saturate+0x12b/0x140 Call Trace: vsock_remove_bound+0x18f/0x280 __vsock_release+0x371/0x480 vsock_release+0x88/0x120 __sock_release+0xaa/0x260 sock_close+0x14/0x20 __fput+0x35a/0xaa0 task_work_run+0xff/0x1c0 do_exit+0x849/0x24c0 make_task_dead+0xf3/0x110 rewind_stack_and_make_dead+0x16/0x20 [1]: https://lore.kernel.org/netdev/CAGxU2F5zhfWymY8u0hrKksW8PumXAYz-9_qRmW==92oAx1BX3g@mail.gmail.com/ Suggested-by: Stefano Garzarella Signed-off-by: Michal Luczaj Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20250611-vsock-test-inc-cov-v3-3-5834060d9c20@rbox.co Signed-off-by: Jakub Kicinski

vsock/test: Add test for an unexpectedly lingering close()

2025-05-27T09:05:22+00:00

There was an issue with SO_LINGER: instead of blocking until all queued messages for the socket have been successfully sent (or the linger timeout has been reached), close() would block until packets were handled by the peer. Add a test to alert on close() lingering when it should not. Signed-off-by: Michal Luczaj Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20250522-vsock-linger-v6-5-2ad00b0e447e@rbox.co Signed-off-by: Paolo Abeni

vsock/test: Introduce enable_so_linger() helper

2025-05-27T09:05:21+00:00

Add a helper function that sets SO_LINGER. Adapt the caller. Signed-off-by: Michal Luczaj Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20250522-vsock-linger-v6-4-2ad00b0e447e@rbox.co Signed-off-by: Paolo Abeni

vsock/test: Introduce vsock_wait_sent() helper

2025-05-27T09:05:21+00:00

Distill the virtio_vsock_sock::bytes_unsent checking loop (ioctl SIOCOUTQ) and move it to utils. Tweak the comment. Signed-off-by: Michal Luczaj Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20250522-vsock-linger-v6-3-2ad00b0e447e@rbox.co Signed-off-by: Paolo Abeni

vsock/test: check also expected errno on sigpipe test

2025-05-17T01:01:32+00:00

In the sigpipe test, we expect send() to fail, but we do not check if send() fails with the errno we expect (EPIPE). Add this check and repeat the send() in case of EINTR as we do in other tests. Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20250514141927.159456-4-sgarzare@redhat.com Signed-off-by: Jakub Kicinski

vsock/test: retry send() to avoid occasional failure in sigpipe test

2025-05-17T01:01:32+00:00

When the other peer calls shutdown(SHUT_RD), there is a chance that the send() call could occur before the message carrying the close information arrives over the transport. In such cases, the send() might still succeed. To avoid this race, let's retry the send() call a few times, ensuring the test is more reliable. Sleep a little before trying again to avoid flooding the other peer and filling its receive buffer, causing false-negative. Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20250514141927.159456-3-sgarzare@redhat.com Signed-off-by: Jakub Kicinski