On Thu, May 07, 2026 at 10:18:05AM -0700, Jakub Kicinski wrote:
On Thu, 7 May 2026 09:32:24 -0700 Eric Dumazet wrote:
On Thu, May 7, 2026 at 9:05 AM Stefano Garzarella <[email protected]> wrote:
> On Thu, May 07, 2026 at 07:33:40AM -0700, Jakub Kicinski wrote:
> >We can revert if you think that the risk of regression is high..
> >Please LMK soon, we can do it before patch reaches Linus.
>
> Some tests in tools/testing/vsock/vsock_test.c are failing with this
> patch applied.
>
> Test 18 are failing sometime in this way (I guess because we are
> dropping packets):
>
> 18 - SOCK_STREAM MSG_ZEROCOPY...hash mismatch
>
> Test 22 is failing 100% in this way:
>
> 22 - SOCK_STREAM virtio credit update + SO_RCVLOWAT...send failed:
> Resource temporarily unavailable
>
>
> With my followup patch adding also advertisement to the other peer
> (still draft locally, waiting for Michael proposal) I saw 22 failing,
> because tests expects that can use the entire buf_alloc, but now we are
> reducing it. So IMO we should do like in `__sock_set_rcvbuf()` and
> double the buffer size, or at least digest an overhead equal to the
> buffer size set by the user via SO_VM_SOCKETS_BUFFER_SIZE (yeah,
> AF_VSOCK has it owns sockopt since the beginning :-().
>
> With that approach tests are passing, but I'd like to stress a bit more
> that patch. I'll send it tomorrow as fixup of this patch, or if you
> prefer to revert, I'll send as standalone.
A plain revert is a big issue, now users now how to crash hypervisors.
This vulnerability allows a compromised guest (controlling
virtio_vsock_hdr fields)
to continuously flood the host's vsock receive queue without
triggering any memory
accounting limits or reader wakeups, resulting in unbounded host
kernel memory consumption (Host DoS via OOM).
A vulnerability where a KVM guest can crash or deadlock its host is
classified as a KVM DoS.
Am I missing something?
Alright, let's leave it.
I posted a potential fixup:
https://lore.kernel.org/netdev/[email protected]/
Thanks,
Stefano
