kernel/linux.git/tools/testing/vsock/vsock_test.c, branch v7.1

vsock/test: add MSG_PEEK after partial recv test

2026-04-17T02:34:22+00:00

Add a test that verifies MSG_PEEK works correctly after a partial recv(). This is to test a bug that was present in the `virtio_transport_stream_do_peek()` when computing the number of bytes to copy: After a partial read, the peek function didn't take into consideration the number of bytes that were already read. So peeking the whole buffer would cause an out-of-bounds read, that resulted in a -EFAULT. This test does exactly this: do a partial recv on a buffer, then try to peek the whole buffer content. The test re-uses `test_stream_msg_peek_client()` to also cover this scenario. Reviewed-by: Stefano Garzarella Signed-off-by: Luigi Leonardi Link: https://patch.msgid.link/20260415-fix_peek-v4-3-8207e872759e@redhat.com Signed-off-by: Jakub Kicinski

vsock/test: fix MSG_PEEK handling in recv_buf()

2026-04-17T02:34:22+00:00

`recv_buf` does not handle the MSG_PEEK flag correctly: it keeps calling `recv` until all requested bytes are available or an error occurs. The problem is how it calculates the number of bytes read: MSG_PEEK doesn't consume any bytes and will re-read the same bytes from the buffer head, so summing the return value every time is wrong. Moreover, MSG_PEEK doesn't consume the bytes in the buffer, so if more bytes are requested than are available, the loop will never terminate, because `recv` will never return EOF. For this reason, we need to compare the number of bytes read with the number of bytes expected. Add a check: if the MSG_PEEK flag is present, update the byte counter and break out of the loop only after at least the expected number of bytes have been received; otherwise, retry after a short delay to avoid consuming too many CPU cycles. This allows us to simplify the `test_stream_credit_update_test` by reusing `recv_buf`, like some other tests already do. Suggested-by: Stefano Garzarella Signed-off-by: Luigi Leonardi Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20260415-fix_peek-v4-2-8207e872759e@redhat.com Signed-off-by: Jakub Kicinski

vsock/test: add stream TX credit bounds test

2026-01-22T14:41:33+00:00

Add a regression test for the TX credit bounds fix. The test verifies that a sender with a small local buffer size cannot queue excessive data even when the peer advertises a large receive buffer. The client: - Sets a small buffer size (64 KiB) - Connects to server (which advertises 2 MiB buffer) - Sends in non-blocking mode until EAGAIN - Verifies total queued data is bounded This guards against the original vulnerability where a remote peer could cause unbounded kernel memory allocation by advertising a large buffer and reading slowly. Suggested-by: Stefano Garzarella Signed-off-by: Melbin K Mathew [Stefano: use sock_buf_size to check the bytes sent + small fixes] Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20260121093628.9941-5-sgarzare@redhat.com Acked-by: Michael S. Tsirkin Signed-off-by: Paolo Abeni

vsock/test: fix seqpacket message bounds test

2026-01-22T14:41:33+00:00

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

vsock/test: Add test for a linear and non-linear skb getting coalesced

2026-01-16T03:44:44+00:00

Loopback transport can mangle data in rx queue when a linear skb is followed by a small MSG_ZEROCOPY packet. To exercise the logic, send out two packets: a weirdly sized one (to ensure some spare tail room in the skb) and a zerocopy one that's small enough to fit in the spare room of its predecessor. Then, wait for both to land in the rx queue, and check the data received. Faulty packets merger manifests itself by corrupting payload of the later packet. Signed-off-by: Michal Luczaj Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20260113-vsock-recv-coalescence-v2-2-552b17837cf4@rbox.co Signed-off-by: Jakub Kicinski

vsock/test: Test setting SO_ZEROCOPY on accept()ed socket

2026-01-06T00:14:51+00:00

Make sure setsockopt(SOL_SOCKET, SO_ZEROCOPY) on an accept()ed socket is handled by vsock's implementation. Reviewed-by: Stefano Garzarella Signed-off-by: Michal Luczaj Link: https://patch.msgid.link/20251229-vsock-child-sock-custom-sockopt-v2-2-64778d6c4f88@rbox.co Signed-off-by: Jakub Kicinski

vsock/test: Extend transport change null-ptr-deref test

2025-11-26T03:16:21+00:00

syzkaller reported a lockdep lock order inversion warning[1] due to commit 687aa0c5581b ("vsock: Fix transport_* TOCTOU"). This was fixed in commit f7c877e75352 ("vsock: fix lock inversion in vsock_assign_transport()"). Redo syzkaller's repro by piggybacking on a somewhat related test implemented in commit 3a764d93385c ("vsock/test: Add test for null ptr deref when transport changes"). [1]: https://lore.kernel.org/netdev/68f6cdb0.a70a0220.205af.0039.GAE@google.com/ Signed-off-by: Michal Luczaj Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20251123-vsock_test-linger-lockdep-warn-v1-1-4b1edf9d8cdc@rbox.co Signed-off-by: Jakub Kicinski

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