From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 98A2934B1A6; Tue, 21 Jul 2026 21:46:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784670384; cv=none; b=A7pSxgmqkUEo7ZDx424dWpQyCYIw3ly6nwEa0hUdTjaDjnFqXxq0K/wh8LO+FmCDFw2o9cDgEyQL9tfvcJmuaJn37tU7Fdra9xENbEtDKtxCB/+lxFZ3CnuNKLsvN4xPyxBnTuJzkTt+hNB004NE527StIxNTgpSojQeMCVFGZE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784670384; c=relaxed/simple; bh=t6aqyVIHQzQAGkSwH2HTubBI59AM0i/lB25MyTvP67w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dxCjJLpYt+rLDXsQStsGJxNh6UtNudG6zxtSq9uXVSaAG1AYE8BIpnkTQtDpDiWGflcXAS19eT9dyWu3ODj3sIIH3Ff+AS0vduy+2p3yFHiGHiL1oGBo9/7gkHLy3G1xYQpPQmtbSu+FcZaBdQcrIjhFK4kAx7az+jqgXBiicsc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=zyQMw/HQ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="zyQMw/HQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 118701F000E9; Tue, 21 Jul 2026 21:46:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1784670383; bh=vNvD1z6slMvgGU4N8pJ82cXhfhCj/onX9iAk0wlHOz0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=zyQMw/HQEd8kbM/9ZZFtiz0F0MWP5Bavs8Czk497A22396y8eT1mPvHz/oAHolfaB aGnye4iX3ZpM7D6G3ui6MY4MQ8osD5NGqpeUsQnC2Tz7aSii9qyfPyzkNbLArVIqV2 srLuktaHG47OxE2lu5oc7xtd20pYTlNhK7FSe3Mk= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Yizhou Zhao , Yuxiang Yang , Ao Wang , Xuewei Feng , Qi Li , Ke Xu , Florian Westphal Subject: [PATCH 6.1 0912/1067] ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Date: Tue, 21 Jul 2026 17:25:13 +0200 Message-ID: <20260721152444.936744621@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260721152424.521567757@linuxfoundation.org> References: <20260721152424.521567757@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Yizhou Zhao commit 2975324d164c552b028632f107b567302863b7f6 upstream. Commit 9a05475cebdd ("ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing "reset struct ip_vs_seq" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later. Fixes: 9a05475cebdd ("ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Assisted-by: Claude-Code:GLM-5.2 Signed-off-by: Yizhou Zhao Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman --- net/netfilter/ipvs/ip_vs_conn.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/netfilter/ipvs/ip_vs_conn.c +++ b/net/netfilter/ipvs/ip_vs_conn.c @@ -996,8 +996,8 @@ ip_vs_conn_new(const struct ip_vs_conn_p cp->app = NULL; cp->app_data = NULL; /* reset struct ip_vs_seq */ - cp->in_seq.delta = 0; - cp->out_seq.delta = 0; + memset(&cp->in_seq, 0, sizeof(cp->in_seq)); + memset(&cp->out_seq, 0, sizeof(cp->out_seq)); atomic_inc(&ipvs->conn_count); if (flags & IP_VS_CONN_F_NO_CPORT)