From nobody Mon Jun 8 14:36:11 2026 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AB33D367F36 for ; Thu, 28 May 2026 22:34:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780007660; cv=none; b=FzdQJ+0jS6tRKj2GGupNSUnUK5wMl8cMschKlzyOUUVyaT3JWcP3ilTpmY48aybb2a6QiQQVNYOdjsrENWI2Htw8LRl0o9MH2NEJTTTSkeJpv3lqFzMVWtmjMT8y2rZdvl8fx6t/ophRomelYeWzZ+jsZ/EXcbaLalDa0HDB02M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780007660; c=relaxed/simple; bh=xjHdc+vc12MKCZBHKVjl8PEg9uX/avR1IAYxPXPh5jA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ihgiOoQuPKwiE1WHDbd4jZhlRp66Tm3NzUHVy5laRwZRYFiRsjmHXyXF2TVWckdfy5CvqDqVdrGT/SXE6W2l4cR/yoUnq2rDctBN/Dmw1L0SyuPBSOP3liJY1ifKUvR8aSRZl37+tlcqD+wO2xVsxwTrdGYniYQg1160zSZiNrs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=e0nCwRC4; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="e0nCwRC4" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49050ff7cbdso58160155e9.2 for ; Thu, 28 May 2026 15:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780007657; x=1780612457; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=mFy+qmKG40w4ZnEG39ULoB2AQiEuE/T4yBXKnfStJQU=; b=e0nCwRC4MYMX0NUvqz1odXpI04NBxW5keCFo5cwlmQnGVFWktenlyOhOnQ2otR0jfS r7ToCROIfMOTKaX7WtJho+FozZ3UwUyqgBaXEt7QZqJ3pTuMyYKU4Ns9wOdnBfsZBV9V LGq+Gq5HU+QgVUeurKVze5+SRnxAvSwEnvFGRbV4VYT12k0K3gmX/cuuc2pFFPN2G+w5 E8nCdTYaiPoMJTOGJvuKLfxcjlqze28mKMhSqfAMxBIuozRfYFD4nO3RjwwAh9I0c+UL wJRaasuqe/d/riPUvqqjXTBonS+kLudh6eXor/fl5LufUDpbBXuzC9/8WYCKZlX5yMC2 UG/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780007657; x=1780612457; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=mFy+qmKG40w4ZnEG39ULoB2AQiEuE/T4yBXKnfStJQU=; b=LM+rX1ugpM5bI+/Asw7txbLKqDgcsQ7T5OgHbGrYO/81RFCK8hK9aoFVvLRSBcR/0N qTIkN7OrBnjS/4mAYMl01+TKniy3GJGPcUBPmwI5dHWfY7q1oRT27KIAmjJNCwRHlKOH g35h5qAQ7sgs3p6FfnjqQbwqtqe081rSq0vgmQSwIg2gf35V8m+2s1ldcQXMyMN2vMZ1 JQGOSoZ3/nD5EHBz4Y3rvFJ7Ap6PbIaWZACy9QzMILbkTJ1eyVi9IPZTwK1Svb+v3N62 kddgesWteAPY90tv6c4c8aKn0xukm+aiRGsusGsBjb63lFGu5batv6/MxcR2nC3jnrIM iOew== X-Forwarded-Encrypted: i=1; AFNElJ/+t5byuK5qtSGnZwo/n+i2a6lSMjl+3FM2wyL5XiLHjtJu4JY7W2P05eevW2o6c4TFjCpYOvv4EGtGTtM=@vger.kernel.org X-Gm-Message-State: AOJu0Yz/lF4CSWQLRKL5UJHATSFW16Xm5oIJg3ogu5doyk7DpL8MsUpk L2hwSPtVpWPWgcvYYvaFRa5NWdW8PNeK5sn1bJvVCC67mFXpdPK5bIj/ X-Gm-Gg: Acq92OE5+3xQLqExbkDEpT+t5vhkDOjJsVYFxoOTmxL/ZQ29eMwKME7PxewXqV+Oihc zY9d+VkJY+DUyCO3hIKTM+hUREs8svqwZzF3+vSRnMD1vQMwdfFXkds++cVIIMTjDhRzkv+SDwY EE8hSjorX9qoN5GkMdRoBZY89BjclPmy5J3Pc1fHa3eXlT+nqgabxvJKrw421MMd0bKf/FbLJNg ZO90MLg+9UdGTO0n7hrcgIIRZh6b9K5mfAAO+CKwQ1LRVmP24OmH9uQd4eYzPKuKWxCNf47SsxU OSacIUbgVZTSa0FloljmpMytdpa9d/mhffmJujNx00AXizWuIBd5525nkM7ZtYUHD1V2LfL6u1k xluAAb1xLwMBqSd39ag11n6IHiYNdUiWai6oCiKbsF3U3FYVXzlYYLlaAgB8w92Dd6ddhgtOGJW HaCF+Rd06k9NiZ71HB/8T5DpmxuLU284XV/JAyEbNndsf2ZiaPDoL7wKTwgLPSC3BNRDTkHlOPX 79SJzDh8vPL0HP4J9IHsulTHMHDIe2ZfkH+VtWcg2UYYV5G X-Received: by 2002:a05:600c:c047:b0:48a:9540:1a3a with SMTP id 5b1f17b1804b1-4909c07faa8mr4076425e9.8.1780007656895; Thu, 28 May 2026 15:34:16 -0700 (PDT) Received: from britney-pc.tail2180da.ts.net (host81-152-149-195.range81-152.btcentralplus.com. [81.152.149.195]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4909caa7e17sm2611475e9.9.2026.05.28.15.34.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2026 15:34:16 -0700 (PDT) From: Kacper Kokot To: netfilter-devel@vger.kernel.org Cc: pablo@netfilter.org, kadlec@netfilter.org, fmancera@suse.de, fw@strlen.de, david.laight.linux@gmail.com, Kacper Kokot , Phil Sutter , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] netfilter: TCPMSS: fix dropped packets when MSS option is unaligned Date: Thu, 28 May 2026 23:34:11 +0100 Message-ID: <20260528223412.27311-1-kacper.kokot.44@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260528204020.7ae744ab@pumpkin> References: <20260528204020.7ae744ab@pumpkin> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Padding TCP options with NOPs is optional, so it is legal to send an MSS option that is not aligned to a word boundary and therefore not aligned for checksum calculation. The current TCPMSS target is not robust to this: when the MSS option is unaligned it produces an invalid checksum, and the packet is dropped. This has not been observed in any real environment. Senders place the MSS at the beginning of the options block, where it is naturally aligned, but the spec allows unaligned options and the kernel shouldn't silently drop legal packets. When the changed word is not aligned, the modified bytes straddle two checksum words, and using the standard incremental update helper (which assumes alignment) produces an invalid checksum: | w1 | w2 | OLD | a b | c d | NEW | a b' | c' d | Since b' and c' sit across w1 and w2, we could compute the incremental checksum in two operations by recalculating w1 and then w2: C' =3D C - w1 + w1' - w2 + w2' But working it out: C' =3D C - w1 - w2 + w1' + w2' =3D C - (a * 2^8 + b) - (c * 2^8 + d) + (a * 2^8 + b') + (c' * 2^8 + d) =3D C + 2^8 * (a - a + c' - c) + (b' - b + d - d) =3D C + 2^8 * (c' - c) + (b' - b) =3D C - (2^8 * c + b) + (2^8 * c' + b') So an unaligned incremental checksum can be done in a single operation by byteswapping the changed bytes before passing them to the helper. This patch implements that trick for unaligned MSS option updates. Signed-off-by: Kacper Kokot --- I decided to go with the get_unaligned_be16 suggestion because it's idiomatic and it produces shorter assembly on x86-64 (6 instructions vs 9). SYN processing is a cold path so I didn't look into it further. v2: - Use get_unaligned_be16 (Fernando's suggestion) - Fix alignment check expression (David) - Mention it's a theoretical bug in the commit message - Drop cc stable, the bug is only theoretical net/netfilter/xt_TCPMSS.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/net/netfilter/xt_TCPMSS.c b/net/netfilter/xt_TCPMSS.c index 80e1634bc51f..32c87a520361 100644 --- a/net/netfilter/xt_TCPMSS.c +++ b/net/netfilter/xt_TCPMSS.c @ -117,8 +117,9 @@ tcpmss_mangle_packet(struct sk_buff *skb, for (i =3D sizeof(struct tcphdr); i <=3D tcp_hdrlen - TCPOLEN_MSS; i +=3D= optlen(opt, i)) { if (opt[i] =3D=3D TCPOPT_MSS && opt[i+1] =3D=3D TCPOLEN_MSS) { u_int16_t oldmss; + u16 csum_oldmss, csum_newmss; =20 - oldmss =3D (opt[i+2] << 8) | opt[i+3]; + oldmss =3D get_unaligned_be16(&opt[i+2]); =20 /* Never increase MSS, even when setting it, as * doing so results in problems for hosts that rely @@ -130,8 +131,19 @@ tcpmss_mangle_packet(struct sk_buff *skb, opt[i+2] =3D (newmss & 0xff00) >> 8; opt[i+3] =3D newmss & 0x00ff; =20 + csum_oldmss =3D htons(oldmss); + csum_newmss =3D htons(newmss); + + /* MSS may be unaligned; fix up the incremental checksum + * to avoid an invalid checksum and a dropped packet. + */ + if (((char *)&opt[i + 2] - (char *)tcph) & 0x1) { + csum_oldmss =3D swab16(csum_oldmss); + csum_newmss =3D swab16(csum_newmss); + } + inet_proto_csum_replace2(&tcph->check, skb, - htons(oldmss), htons(newmss), + csum_oldmss, csum_newmss, false); return 0; } --=20 2.43.0