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: > >On Thu, 7 May 2026 14:59:13 +0200 Stefano Garzarella wrote: > >> >well if you want to support pathological cases such as 1 byte messages > >> >that would mean like 100x reduction no? > >> > >> Yep, but since this patch is already merged, IMHO that is better than > >> losing data in those pathological cases. > > > >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?
