From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.195 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792498376; b=r35K9eavj/etKhMtqOB15+ndcrpaQ6DBtSxrN2xl/43+C2gNE6Q8jkV/ojK8e+iVYhR/ 3v3m7/BbNQOVlithm53dMEmK6N/HMHKXISsYdHRyvg40Yx/IGE2Yy5OBXpEMcDYjnopmj H43M5QBHyPV3l+sFrC2h3HajlSGeryvN/XxzzV0hbAB9KwmqNErQ/obyCECq550213I+u ejxHOFCNriIIoqHzzwrNCdZnwKTID0A5MU0a2b9xKyeDWRWgNGGOQ3jsI0qewTYQYLzUq GjloH88OESlvnUIoVNIJObWMzX2C7IQxWtVwxuAKKreG5ha4PvbqFZ9eSM/jeScNJ0Q== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792498376; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:From:To:Cc:Subject:Date:Message-ID: X-Mailer:MIME-Version:Content-Transfer-Encoding; bh=+3aP9S+I4hN8ayAzr2FdVXGfcpVuzHhgRmKY7lrV5LU=; b=EP5U8yXhXxZlIzq3ZOnSoX7WqsStdyJi6+45+P1o96V/M1VCToNBUuUC4OSBokonlhdx D8PLEjufUF/Zr3ds8QrHec/6td1TbtFLvfs66v7q835vAkf0AQRQLGYadNS5acYrjDf2J XPJDmfN6N4cBK9gMflizGHFCvdxWyceEFzRZGjLG9msHMoVnv0QrDtGplXxjXvX/APRFr 4HfTMw34o6rOnfR/yhaS3uWMkMhqhSl1PcRU94qSLK2yKBWRbmYSePx5LYwtwC/44N24d Hf91sgLOR5eUZIrQHwZVO6NkQu5IsNh95wbo9NDIFezab98hGLm5b46ZR0HgktdZu3g== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=q9KMvSBE; arc=none smtp.remote-ip=91.218.175.195 Received: from mta0.migadu.com (out-195.mta0.migadu.com [91.218.175.195]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E1405606A319 for ; Tue, 20 Oct 2026 12:12:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org E1405606A319 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=q9KMvSBE X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=pHt6jSjv0iNign9HC3Cohxdp/lbHFVpVVhQ1kwkIEhI=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1792498374; v=1; x=1793103174; b=q9KMvSBEXRZHEK7AmP+Eif3Mgy+vhxvZyI3cUHdSMzwUHcO4qE8bE+CfIe66VaLGQdYy0Dxm WIo5Il2/9bQn+o4baJa3+fguXruOvYOMx0B/Ruj0jZO5nfUH+vje3qV6wrH26Bmo+ITI94HQtyh Z412TWwJm+E6cBRxokIjMPII= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id c323d3c4687816b9; Tue, 20 Oct 2026 12:12:54 +0000 X-Mizu-Trace-ID: c323d3c4687816b9 X-Migadu-Flow: FLOW_OUT From: Jiayuan Chen To: netdev@vger.kernel.org, sd@queasysnail.net Cc: Jiayuan Chen , John Fastabend , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Wilfred Mallawa , linux-kernel@vger.kernel.org Subject: [PATCH net v3] tls: fix the open record check in the max payload size setsockopt Date: Tue, 20 Oct 2026 20:12:39 +0800 Message-ID: <20261020121240.29082-1-jiayuan.chen@linux.dev> X-Mailer: git-send-email 2.43.0 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit do_tls_setsockopt_tx_payload_len() refuses to resize records while one is open, but the check is broken in two ways. It reaches for the open record through tls_sw_ctx_tx(), an unchecked cast of ctx->priv_ctx_tx. Under device offload that pointer is a tls_offload_context_tx, so the check reads a field of the wrong struct: it returns EBUSY on whatever happens to be there, and never sees the record that really is open. Dispatch on tx_conf. The socket lock alone is also not enough to tell no sender is in flight. The device tx path drops it in sk_stream_wait_memory() after tls_push_record() cleared open_record, so setsockopt can slip in mid-sendmsg and shrink the limit. tls_push_data() latches the limit once per call, and a record left open by MSG_MORE can then be bigger than the new limit, making the u32 subtraction in the copy clamp wrap around and build an oversized record. Take tx_lock like the sendmsg paths do so setsockopt waits for in-flight senders. Re-reading the limit inside the tls_push_data() loop could close the wrap too, but a parked sender would still finish with the old limit, so serializing on tx_lock is simpler. Take tx_lock interruptible, as tls_sw_sendmsg() does. Both sendmsg paths keep it across sk_stream_wait_memory(), which sleeps until the peer reads, so a plain mutex_lock() could park setsockopt in D state for as long as the sender waits. The lock_sock() after it is fine uninterruptible: a sender sleeping for memory has released the socket lock, so that wait only covers short critical sections, like every other setsockopt. Fixes: 82cb5be6ad64 ("net/tls: support setting the maximum payload size") Signed-off-by: Jiayuan Chen --- v2 -> v3: - no code change, explain why tx_lock is taken interruptible, in the commit message and the comment (Paolo) - resend, v2 was marked "changes requested" in patchwork, thanks to Sabrina for the reminder: https://lore.kernel.org/netdev/atdJUP6Jb0jODBYE@krikkit/ v2: https://lore.kernel.org/all/20260901072927.128688-1-jiayuan.chen@linux.dev/ v1 -> v2: - also take tx_lock in setsockopt, the socket lock alone can't stop a device sender parked in sk_stream_wait_memory() (AI review on v1) v1: https://lore.kernel.org/netdev/20260831025607.62927-1-jiayuan.chen@linux.dev/ base on my netdevsim + tls (in progress) https://lore.kernel.org/netdev/20260728125658.390500-1-jiayuan.chen@linux.dev/ Previous finding: b17cf742eaad ("tls: device: fix out-of-bounds write in tls_append_frag()") --- net/tls/tls_main.c | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c index 8bdb78718a8d..42ab291eee42 100644 --- a/net/tls/tls_main.c +++ b/net/tls/tls_main.c @@ -831,15 +831,29 @@ static int do_tls_setsockopt_no_pad(struct sock *sk, sockptr_t optval, return rc; } +/* priv_ctx_tx holds a different structure on each TX path, so tx_conf has to + * say which open record to look at. + */ +static bool tls_tx_record_is_open(struct tls_context *ctx) +{ + switch (ctx->tx_conf) { + case TLS_SW: + return !!tls_sw_ctx_tx(ctx)->open_rec; + case TLS_HW: + return !!tls_offload_ctx_tx(ctx)->open_record; + default: + return false; + } +} + static int do_tls_setsockopt_tx_payload_len(struct sock *sk, sockptr_t optval, unsigned int optlen) { struct tls_context *ctx = tls_get_ctx(sk); - struct tls_sw_context_tx *sw_ctx = tls_sw_ctx_tx(ctx); u16 value; bool tls_13 = ctx->prot_info.version == TLS_1_3_VERSION; - if (sw_ctx && sw_ctx->open_rec) + if (tls_tx_record_is_open(ctx)) return -EBUSY; if (sockptr_is_null(optval) || optlen != sizeof(value)) @@ -860,6 +874,7 @@ static int do_tls_setsockopt_tx_payload_len(struct sock *sk, sockptr_t optval, static int do_tls_setsockopt(struct sock *sk, int optname, sockptr_t optval, unsigned int optlen) { + struct tls_context *ctx; int rc = 0; switch (optname) { @@ -879,9 +894,18 @@ static int do_tls_setsockopt(struct sock *sk, int optname, sockptr_t optval, rc = do_tls_setsockopt_no_pad(sk, optval, optlen); break; case TLS_TX_MAX_PAYLOAD_LEN: + /* Take tx_lock like the sendmsg paths do, the socket lock is + * dropped while a sender waits for memory, maybe with no record + * open. Senders sleep with tx_lock held, so take it interruptible. + */ + ctx = tls_get_ctx(sk); + rc = mutex_lock_interruptible(&ctx->tx_lock); + if (rc) + break; lock_sock(sk); rc = do_tls_setsockopt_tx_payload_len(sk, optval, optlen); release_sock(sk); + mutex_unlock(&ctx->tx_lock); break; default: rc = -ENOPROTOOPT; -- 2.43.0