Re: [PATCH bpf v2 4/4] selftests/bpf: Fail unbound UDP on sockmap update

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing check for `socket()` failure leads to a false positive test pass.
--

commit 7f8484db13c3ae1f9676009ab7e283f2b68e4ae0
Author: Michal Luczaj <mhal@rbox.co>

selftests/bpf: Fail unbound UDP on sockmap update

This commit modifies test_maps to expect a failure when updating a sockmap
with an unbound UDP socket. It effectively reverts a previous selftests
change now that sockmap rejects unbound UDP sockets.

> diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c
> --- a/tools/testing/selftests/bpf/test_maps.c
> +++ b/tools/testing/selftests/bpf/test_maps.c
> @@ -759,12 +759,12 @@ static void test_sockmap(unsigned int tasks, void *data)
>  		goto out_sockmap;
>  	}
>  
> -	/* Test update with unsupported UDP socket */
> +	/* Test update with unsupported unbound UDP socket */
>  	udp = socket(AF_INET, SOCK_DGRAM, 0);
>  	i = 0;
>  	err = bpf_map_update_elem(fd, &i, &udp, BPF_ANY);

[Severity: Medium]
Will test_sockmap() in tools/testing/selftests/bpf/test_maps.c now silently
pass if socket() fails to create a file descriptor?

Because this patch changes the logic to expect an error from
bpf_map_update_elem() by checking if (!err), if socket() returns -1 due to
setup failures, bpf_map_update_elem() will fail with an error like -EBADF.

This would cause the test to erroneously pass without actually testing the
kernel's behavior for unbound UDP sockets. Does this test need a check to
ensure the returned udp file descriptor is valid before proceeding with the
map update?

> -	if (err) {
> -		printf("Failed socket update SOCK_DGRAM '%i:%i'\n",
> +	if (!err) {
> +		printf("Failed allowed unbound SOCK_DGRAM socket update '%i:%i'\n",
>  		       i, udp);
>  		goto out_sockmap;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260626-sockmap-lookup-udp-leak-v2-0-7e7e201c951a@rbox.co?part=4