From: Paolo Abeni Date: Thu, 22 Jan 2026 14:41:35 +0000 (+0100) Subject: Merge branch 'vsock-virtio-fix-tx-credit-handling' X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=5778d65d4b85d4929d30998863e08e20af4b6113;p=thirdparty%2Fkernel%2Flinux.git Merge branch 'vsock-virtio-fix-tx-credit-handling' Stefano Garzarella says: ==================== vsock/virtio: fix TX credit handling The original series was posted by Melbin K Mathew till v4. Since it's a real issue and the original author seems busy, I'm sending the new version fixing my comments but keeping the authorship (and restoring mine on patch 2 as reported on v4). v5: https://lore.kernel.org/netdev/20260116201517.273302-1-sgarzare@redhat.com/ v4: https://lore.kernel.org/netdev/20251217181206.3681159-1-mlbnkm1@gmail.com/ From Melbin K Mathew : This series fixes TX credit handling in virtio-vsock: Patch 1: Fix potential underflow in get_credit() using s64 arithmetic Patch 2: Fix vsock_test seqpacket bounds test Patch 3: Cap TX credit to local buffer size (security hardening) Patch 4: Add stream TX credit bounds regression test The core issue is that a malicious guest can advertise a huge buffer size via SO_VM_SOCKETS_BUFFER_SIZE, causing the host to allocate excessive sk_buff memory when sending data to that guest. On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. With this series applied, the same PoC shows only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive. ==================== Link: https://patch.msgid.link/20260121093628.9941-1-sgarzare@redhat.com Signed-off-by: Paolo Abeni --- 5778d65d4b85d4929d30998863e08e20af4b6113