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.
