From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 55D4021C187; Tue, 12 Aug 2025 19:07:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755025662; cv=none; b=KoAGcYNZeCYdGdVnqVxudfcCCAz+9HE2FZRQ31TGEIWFYWK5AkJqNoE3aIiJI5UqxcG/b+UDreGyzT0Ia1J++ayOUzBRMTyV+dNxCVaKkLVX4aMt6HZEdsdLzrPUs3VJNg61+YxJgyJIwFVD62VSkVE+CowCv3kWqE2SFILWGCM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755025662; c=relaxed/simple; bh=HeTKE57juOfO9UGjdwikkKl9Zf4iiuK7E//UWrQ5lt4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TwO0OIlOFAtuxf2I2lMrD29Sn7agoGo9lHqZL8uEnOLq/C5agE9d0Hg3AKi1yEnEwRXN59xTsw0WUos2Ig6VBsXSOi8abpkfD6o4UhSW5YG8zdrSeT25c94r22dJvT4Bl/CceYWBvOFE4rVDFWaGvko8TnuAZhT5fQokF7oTNoI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=yKupqL88; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="yKupqL88" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B95E9C4CEF0; Tue, 12 Aug 2025 19:07:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1755025662; bh=HeTKE57juOfO9UGjdwikkKl9Zf4iiuK7E//UWrQ5lt4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yKupqL88AtCt5WtfTPxx0nFEmd0WQQW9bXJjGOywDh1p5DxK2GdI2zKuVDgR9u1MO lMzeVdUX0rzfTxoC9HM7dbVxCuR+dRmQl5OTnyleuFumbkftnfFV9d7OybJhz/xE+/ jqhGwMhwHyFVEw4SCCOTv1nD+keG0DYo7K96OXTg= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Cong Wang , Jiayuan Chen , Daniel Borkmann , John Fastabend , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.15 106/480] bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls Date: Tue, 12 Aug 2025 19:45:14 +0200 Message-ID: <20250812174401.849491878@linuxfoundation.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20250812174357.281828096@linuxfoundation.org> References: <20250812174357.281828096@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jiayuan Chen [ Upstream commit 178f6a5c8cb3b6be1602de0964cd440243f493c9 ] When sending plaintext data, we initially calculated the corresponding ciphertext length. However, if we later reduced the plaintext data length via socket policy, we failed to recalculate the ciphertext length. This results in transmitting buffers containing uninitialized data during ciphertext transmission. This causes uninitialized bytes to be appended after a complete "Application Data" packet, leading to errors on the receiving end when parsing TLS record. Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Reported-by: Cong Wang Signed-off-by: Jiayuan Chen Signed-off-by: Daniel Borkmann Reviewed-by: John Fastabend Acked-by: Jakub Kicinski Link: https://lore.kernel.org/bpf/20250609020910.397930-2-jiayuan.chen@linux.dev Signed-off-by: Sasha Levin --- net/tls/tls_sw.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index fc88e34b7f33..549d1ea01a72 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -872,6 +872,19 @@ static int bpf_exec_tx_verdict(struct sk_msg *msg, struct sock *sk, delta = msg->sg.size; psock->eval = sk_psock_msg_verdict(sk, psock, msg); delta -= msg->sg.size; + + if ((s32)delta > 0) { + /* It indicates that we executed bpf_msg_pop_data(), + * causing the plaintext data size to decrease. + * Therefore the encrypted data size also needs to + * correspondingly decrease. We only need to subtract + * delta to calculate the new ciphertext length since + * ktls does not support block encryption. + */ + struct sk_msg *enc = &ctx->open_rec->msg_encrypted; + + sk_msg_trim(sk, enc, enc->sg.size - delta); + } } if (msg->cork_bytes && msg->cork_bytes > msg->sg.size && !enospc && !full_record) { -- 2.39.5