This series fixes TX credit handling in virtio-vsock:

Patch 1: Fix potential underflow in get_credit() using s64 arithmetic
Patch 2: Cap TX credit to local buffer size (security hardening)
Patch 3: Fix vsock_test seqpacket bounds test
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.
-- 
2.34.1

On Wed, Dec 17, 2025 at 07:12:02PM +0100, Melbin K Mathew wrote:
>This series fixes TX credit handling in virtio-vsock:
>
>Patch 1: Fix potential underflow in get_credit() using s64 arithmetic
>Patch 2: Cap TX credit to local buffer size (security hardening)
>Patch 3: Fix vsock_test seqpacket bounds test
>Patch 4: Add stream TX credit bounds regression test

Again, this series doesn't apply both on my local env but also on 
patchwork:
https://patchwork.kernel.org/project/netdevbpf/list/?series=1034314

Please, can you fix your env?

Let me know if you need any help.

Stefano

>
>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.
>-- 
>2.34.1
>

Hi Melbin and happy new year!

On Thu, Dec 18, 2025 at 10:18:03AM +0100, Stefano Garzarella wrote:
>On Wed, Dec 17, 2025 at 07:12:02PM +0100, Melbin K Mathew wrote:
>>This series fixes TX credit handling in virtio-vsock:
>>
>>Patch 1: Fix potential underflow in get_credit() using s64 arithmetic
>>Patch 2: Cap TX credit to local buffer size (security hardening)
>>Patch 3: Fix vsock_test seqpacket bounds test
>>Patch 4: Add stream TX credit bounds regression test
>
>Again, this series doesn't apply both on my local env but also on 
>patchwork:
>https://patchwork.kernel.org/project/netdevbpf/list/?series=1034314
>
>Please, can you fix your env?
>
>Let me know if you need any help.

Any update on this?
If you have trouble, please let me know.
I can repost fixing the latest stuff.

Thanks,
Stefano

On Thu, Jan 08, 2026 at 12:27:41PM +0100, Stefano Garzarella wrote:
>Hi Melbin and happy new year!
>
>On Thu, Dec 18, 2025 at 10:18:03AM +0100, Stefano Garzarella wrote:
>>On Wed, Dec 17, 2025 at 07:12:02PM +0100, Melbin K Mathew wrote:
>>>This series fixes TX credit handling in virtio-vsock:
>>>
>>>Patch 1: Fix potential underflow in get_credit() using s64 arithmetic
>>>Patch 2: Cap TX credit to local buffer size (security hardening)
>>>Patch 3: Fix vsock_test seqpacket bounds test
>>>Patch 4: Add stream TX credit bounds regression test
>>
>>Again, this series doesn't apply both on my local env but also on 
>>patchwork:
>>https://patchwork.kernel.org/project/netdevbpf/list/?series=1034314
>>
>>Please, can you fix your env?
>>
>>Let me know if you need any help.
>
>Any update on this?
>If you have trouble, please let me know.
>I can repost fixing the latest stuff.

Since it's almost a month without any reply, I fixed the latest stuff 
and sent a v5 here: 
https://lore.kernel.org/netdev/20260116201517.273302-1-sgarzare@redhat.com/

Thanks,
Stefano