On 4/15/26 12:42, Stefano Garzarella wrote: > On Tue, Apr 14, 2026 at 04:22:04PM +0200, Michal Luczaj wrote: >> On 4/9/26 18:34, Norbert Szetei wrote: >>> In vsock_update_buffer_size(), the buffer size was being clamped to the >>> maximum first, and then to the minimum. If a user sets a minimum buffer >>> size larger than the maximum, the minimum check overrides the maximum >>> check, inverting the constraint. >>> >>> This breaks the intended socket memory boundaries by allowing the >>> vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. >>> >>> Fix this by checking the minimum first, and then the maximum. This >>> ensures the buffer size never exceeds the buffer_max_size. >> >> Something may be missing. After adding another ioctl to your reproducer, I >> still see crashes. >> >> SYSCHK(setsockopt(fd, AF_VSOCK, SO_VM_SOCKETS_BUFFER_MIN_SIZE, &min, >> sizeof(min))); >> + SYSCHK(setsockopt(fd, AF_VSOCK, SO_VM_SOCKETS_BUFFER_MAX_SIZE, &min, >> + sizeof(min))); >> } >> >> [*] Setting buffer_min_size to 0x400000000. >> [socket][0] sending... >> >> refcount_t: saturated; leaking memory. >> WARNING: lib/refcount.c:22 at refcount_warn_saturate+0x7d/0xb0, CPU#2: >> a.out/1478 >> ... >> refcount_t: underflow; use-after-free. >> WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x50/0xb0, CPU#12: >> kworker/12:0/80 >> Workqueue: vsock-loopback vsock_loopback_work >> ... >> > > yeah, I pointed out the same during the bug discussion > (https://lore.kernel.org/netdev/acuKUpZQq6z1DY_n@sgarzare-redhat/) and > suggested to add a sysctl or reuse net.core.wmem_max/rmem_max > (https://lore.kernel.org/netdev/adYKERRYwzMIhZAl@sgarzare-redhat/)
Oh, so this patch wasn't meant to tackle the repro from v1. Sorry, I got confused. Michal
