Re: [PATCH net-next 6/6] selftests/vsock: test the assign ioctl privilege checks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The unprivileged user namespace test spuriously fails because the unprivileged user lacks DAC permissions to open `/dev/vsock`.
--

commit 4c5b8557bb5663f827061639a80256407bfe6c8c
Author: Bobby Eshleman <bobbyeshleman@meta.com>

selftests/vsock: test the assign ioctl privilege checks

This commit adds two tests to verify that CAP_NET_ADMIN is required to use
the IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS ioctl, and that an unprivileged user
namespace alone is insufficient.

> diff --git a/tools/testing/selftests/vsock/vmtest.sh b/tools/testing/selftests/vsock/vmtest.sh
> index 53591fa07f1a8..efb94d17d9976 100755
> --- a/tools/testing/selftests/vsock/vmtest.sh
> +++ b/tools/testing/selftests/vsock/vmtest.sh
[ ... ]
> @@ -1805,6 +1817,51 @@ test_ns_guest_assign_g2h_netns_reset_on_ns_delete_ok() {
[ ... ]
> +test_ns_guest_assign_g2h_netns_unpriv_user_ns_fails() {
> +	local helper=/tmp/vsock_assign_g2h_netns
> +	local unpriv_uid=65534
> +	local unpriv
> +	local rc
> +
> +	unpriv="setpriv --reuid=${unpriv_uid} --regid=${unpriv_uid}"
> +	unpriv="${unpriv} --clear-groups"
> +
> +	if ! vm_ssh "init_ns" -- "${unpriv} unshare -U true"; then
> +		log_host "unprivileged user namespaces unavailable, skipping"
> +		return "${KSFT_SKIP}"
> +	fi
> +
> +	# The home shared with the guest is root-only, so place the helper where
> +	# an unprivileged user can execute it.
> +	vm_ssh "init_ns" -- \
> +		"cp ./vsock_assign_g2h_netns ${helper} && chmod 755 ${helper}"
> +
> +	vm_ssh "init_ns" -- "${unpriv} unshare -Urn ${helper}" &>/dev/null
> +	rc=$?
> +
> +	if [[ "${rc}" -ne "${EPERM}" ]]; then

[Severity: Medium]
Will this test spuriously fail in minimal environments like virtme-ng?

The test helper vsock_assign_g2h_netns is executed as an unprivileged user
(UID 65534). In minimal environments without systemd-udevd to modify default
device node permissions, devtmpfs creates /dev/vsock with default 0600
(root:root) permissions since vsock_device in the kernel does not explicitly
specify a mode.

When the unprivileged user tries to open /dev/vsock:

tools/testing/selftests/vsock/vsock_assign_g2h_netns.c:main() {
    ...
	fd = open("/dev/vsock", O_RDONLY);
	if (fd < 0) {
		fprintf(stderr, "open /dev/vsock: %s\n", strerror(errno));
		return -1;
	}
    ...
}

It gets EACCES, causing the C helper to return -1 (exit code 255).

Since the script expects EPERM (exit code 1) from the ioctl failure, does it
misinterpret the 255 exit code as a test failure?

> +		log_host "expected EPERM (${EPERM}) for an unprivileged user, got ${rc}"
> +		return "${KSFT_FAIL}"
> +	fi
> +
> +	return "${KSFT_PASS}"
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902-vsock-guest-ns-v1-0-9995383e9a8b@meta.com?part=6