netdev - Re: [PATCH net-next v7 1/2] net/tls: support setting the maximum payload size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aPeASl1RRAKMmuhC@krikkit>
Date: Tue, 21 Oct 2025 14:44:58 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Wilfred Mallawa <wilfred.opensource@...il.com>
Cc: netdev@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
	"David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Jonathan Corbet <corbet@....net>, Simon Horman <horms@...nel.org>,
	John Fastabend <john.fastabend@...il.com>,
	Shuah Khan <shuah@...nel.org>,
	Wilfred Mallawa <wilfred.mallawa@....com>
Subject: Re: [PATCH net-next v7 1/2] net/tls: support setting the maximum
 payload size

2025-10-21, 19:29:17 +1000, Wilfred Mallawa wrote:
> diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
> index 39a2ab47fe72..b234d44bd789 100644
> --- a/net/tls/tls_main.c
> +++ b/net/tls/tls_main.c
> @@ -541,6 +541,32 @@ static int do_tls_getsockopt_no_pad(struct sock *sk, char __user *optval,
>  	return 0;
>  }
>  
> +static int do_tls_getsockopt_tx_payload_len(struct sock *sk, char __user *optval,
> +					    int __user *optlen)
> +{
> +	struct tls_context *ctx = tls_get_ctx(sk);
> +	u16 payload_len = ctx->tx_max_payload_len;
> +	int len;
> +
> +	if (get_user(len, optlen))
> +		return -EFAULT;
> +
> +	/* For TLS 1.3 payload length includes ContentType */
> +	if (ctx->prot_info.version == TLS_1_3_VERSION)
> +		payload_len++;

I'm not sure why you introduced this compared to v6?

The ContentType isn't really payload (stuff passed to send() by
userspace), so I think the setsockopt behavior (ignoring the extra 1B)
makes more sense.

Either way, we should really avoid this asymmetry between getsockopt
and setsockopt. Whatever value is fed through setsockopt should be
what we get back with getsockopt. Otherwise, the API gets quite
confusing for users.


The rest of the patch looks ok.

-- 
Sabrina