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

On Mon, Sep 07, 2026 at 03:45:54PM +0800, weirongguang wrote:

On 2026/8/24 20:16, David Laight wrote:

quoted

On Mon, 24 Aug 2026 17:12:57 +0800
Rongguang Wei [off-list ref] wrote:

quoted

From: Rongguang Wei <redacted>

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.

quoted

quoted

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