Re: [PATCH net v1] vsock: validate buffer min/max size in setsockopt

[Stefano Garzarella <sgarzare@redhat.com>]

On Mon, Sep 07, 2026 at 03:45:54PM +0800, weirongguang wrote:
>
>
>On 2026/8/24 20:16, David Laight wrote:
>> On Mon, 24 Aug 2026 17:12:57 +0800
>> Rongguang Wei <clementwei90@163.com> wrote:
>>
>>> From: Rongguang Wei <weirongguang@kylinos.cn>
>>>
>>> SO_VM_SOCKETS_BUFFER_MIN_SIZE and SO_VM_SOCKETS_BUFFER_MAX_SIZE
>>> do not cross-validate against each other, allowing userspace to
>>> set buffer_min_size > buffer_max_size.
>>> When min > max, buffer_size is silently clamped to an incorrect
>>> value. For example, setting min=512KB then max=128 results in
>>> buffer_size=128 despite the user requesting much larger buffers
>>> via SO_VM_SOCKETS_BUFFER_SIZE.
>>>
>>> Reproduced with a test program:
>>> setsockopt(fd, AF_VSOCK, SO_VM_SOCKETS_BUFFER_MIN_SIZE,
>>> 	   512 * 1024, sizeof(int));
>>> setsockopt(fd, AF_VSOCK, SO_VM_SOCKETS_BUFFER_MAX_SIZE,
>>> 	   128, sizeof(int));
>>> // User asked for 1MB but got 128 bytes silently
>>> setsockopt(fd, AF_VSOCK, SO_VM_SOCKETS_BUFFER_SIZE,
>>> 	   1024 * 1024, sizeof(int));

The user set MAX_SIZE to 128, from commit d114bfdc9b76 ("vsock: fix 
buffer size clamping order") this is the behavior we wanted, to ensure a 
rational limit on memory usage.

>>>
>>> After that use getsockopt to get the buffer_size = 128 and
>>> buffer_min_size = 524288, buffer_max_size = 128.
>>> The buffer_min_size > buffer_max_size and the kernel accepted
>>> contradictory values without error.
>>>
>>> Add value check to fix this issue. Return -EINVAL to userspace
>>> when setting MAX_SIZE to a value smaller than the current MIN_SIZE
>>> or setting MIN_SIZE to a value larger than the current MAX_SIZE.
>>
>> That is going to break userspace that sets the minimum before the maximum
>> when the new minimum is larger than the old maximum.
>>
>> David
>>
>Hi, David.
>Thanks for pointing out the issue.
>
>Here is an alternative approach:
>instead of returning -EINVAL, automatically adjust the other value to preserve buffer_min_size <= buffer_max_size.
>The trade-off is that setting one parameter may implicitly adjust the other, but this is preferable to breaking existing applications.
>Does this approach look reasonable?

With this fix, how would that change the results of the test program you 
included in the commit description?

Honestly, I don't understand what we're trying to fix.

Stefano