Re: [PATCH bpf-next v2 1/2] bpf: Allow IP_TRANSPARENT and IPV6_TRANSPARENT in bpf_{set,get}sockopt()

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf_setsockopt() bypasses MPTCP subflow synchronization for IP_TRANSPARENT and IPV6_TRANSPARENT.
--

--- Patch [1]: [PATCH bpf-next v2 1/2] bpf: Allow IP_TRANSPARENT and IPV6_TRANSPARENT in bpf_{set,get}sockopt() ---
commit c5ad31eb12f337883443730bb1839d63112c725e
Author: Shivaji Kant <[email protected]>

bpf: Allow IP_TRANSPARENT and IPV6_TRANSPARENT in bpf_{set,get}sockopt()

This commit allows IP_TRANSPARENT and IPV6_TRANSPARENT socket options to be
used with bpf_setsockopt() and bpf_getsockopt().

> diff --git a/net/core/filter.c b/net/core/filter.c
> index c21c1daecf9d1..04a9f9d8d07b4 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -5645,6 +5645,7 @@ static int sol_ip_sockopt(struct sock *sk, int optname,
>  
>  	switch (optname) {
>  	case IP_TOS:
> +	case IP_TRANSPARENT:
>  		if (*optlen != sizeof(int))
>  			return -EINVAL;
>  		break;

[Severity: Medium]
Does bypassing the protocol-specific sk->sk_prot->setsockopt() handler here
break MPTCP subflow synchronization?

Since sol_ip_sockopt() calls do_ip_setsockopt(sk) directly, it appears that
IP_TRANSPARENT settings applied via bpf_setsockopt() will not be synchronized
to existing MPTCP subflows. Could this cause the underlying subflows to lack
the transparent attribute after they are instantiated?

[ ... ]

> @@ -5671,6 +5672,7 @@ static int sol_ipv6_sockopt(struct sock *sk, int optname,
>  	switch (optname) {
>  	case IPV6_TCLASS:
>  	case IPV6_AUTOFLOWLABEL:
> +	case IPV6_TRANSPARENT:
>  		if (*optlen != sizeof(int))
>  			return -EINVAL;
>  		break;

[Severity: Medium]
Will this introduce the same synchronization issue for IPV6_TRANSPARENT on IPv6
MPTCP sockets?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1